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DOD  COMPUTER  SECURITY  INITIATIVE  SEMINAR  -  IV 

August  10-12,  1981 


ABOUT  THU  DOD  COMPUTER  SECURITY  INITIATIVE 

The  Department  of  Defense  (DoD)  Computer  Security  Initiative  was 
established  in  1978  by  the  Assistant  Security  of  Defense  for  Communica¬ 
tions,  Command,  and  Control  and  Intelligence  to  achieve  the  widespread 
availability  of  "trusted"  ADP  systems  for  use  within  the  DoD.  Widespread 
availability  implies  the  use  of  commercially  developed  trusted  ADP 
systems  whenever  possible.  Recent  DoD  research  activities  are  demonstrating 
that  trusted  ADP  systems  can  be  developed  and  successfully  employed  in 
sensitive  information  handling  environments.  In  addition  to  these 
demonstration  systems,  a  technically  sound  and  consistent  evaluation 
procedure  must  be  established  for  determining  the  environments  for  which 
a  particular  trusted  system  is  suitable. 

The  Computer  Security  Initiative  is  attempting  to  foster  the 
development  of  trusted  ADP  systems  through  technology  transfer  efforts 
and  to  define  reasonable  ADP  system  evaluation  procedures  to  be  applied 
to  both  government  and  commercially  developed  trusted  ADP  systems.  This 
seminar  is  the  fourth  in  a  series  which  constitute  an  essential  element 
in  the  Initiative's  Technology  Transfer  Program. 

Effective  January  1,  1981,  the  Director  of  the  National  Security 
Agency  was  assigned  responsibility  for  computer  security  evaluation  for 
the  Department  of  Defense.  Plans  for  the  transfer  of  the  Computer 
Security  Initiative  activities  to  NSA  are  well  underway. 

The  Institute  for  Computer  Sciences  and  Technology,  through  its 
Computer  Security  and  Risk  Management  Standards  program,  seeks  new 
technology  to  satisfy  Federal  ADP  security  requirements.  The  Institute 
then  promulgates  acceptable  and  cost  effective  technology  in  Federal 
Information  Processing  Standards  and  Guidelines.  The  Institute  is 
pleased  to  assist  the  Department  of  Defense  in  transferring  the  interim 
results  of  its  research  being  conducted  under  the  Computer  Security 
Initiative . 

ABOUT  THE  SEMINAR 

This  is  the  fourth  in  a  series  of  seminars  to  acquaint  computer 
system  developers  and  users  with  the  status  of  trusted  ADP  system 
developments  plans  for  the  integrity  evaluation  of  trusted  systems. 

The  three  previous  seminars  have  stressed  user  requirements  for  trusted 
systems  throughout  the  government  and  the  private  sector,  experience 
with  design  of  production  prototype  trusted  systems,  and  industry 
progress  in  computer  security.  The  focus  of  this  seminar  is  on  trusted 
system  efforts  across  the  board. 


ACKNOWLEDGMENTS 


A  number  of  people  in  and  outside  of  the  DoD  Computer  Security  Technical 
Consortium  have  helped  to  make  this  seminar  a  success.  At  the  MITRE  Corporation, 
Pete  Tasker  helped  to  organize  the  speakers;  Karen  Borgeson  and  Dianne  Maz zone 
managed  registration;  Charles  McClure  provided  behind-the-scenes  support. 

Finally  Dr.  Billy  Claybrook  handled  the  entire  job  of  collecting  and  organizing 
the  material  for  this  Proceedings. 

Also,  we  are  grateful  to  Greta  Pignone  and  Sara  R.  Torrence  of  MBS  for 
arranging  the  splendid  facilities. 


DISCLAIMER 

The  presentations  in  this  proceedings  are  provided  for  your  information. 
They  should  not  be  interpreted  as  necessarily  representing  the  official  view 
or  carrying  any  endorsement,  either  expressed  or  implied,  of  the  Department 
of  Defense  or  the  United  States  Government. 


Chairman 

DoD  Computer  Security  Technical 
Consortium 


DOD  COMPUTER  SECURITY  INITIATIVE  SEMINAR  -  IV 


August  10-12,  1981 


Monday,  August  10 
9:30  INTRODUCTION 

Jim  Burrows,  Director 

Institute  for  Computer  Sciences  and  Tecnnology 
National  Bureau  of  Standards 

KEYNOTE  SPEAKER 

Admiral  Bobby  Inman 

Deputy  Director  of  Central  Intelligence 
DOD  Computer  Security  Initiative  Status 

Steve  Walker,  Chairman 

DoD  Computer  Security  Technical  Consortium 

MANUFACTURERS'  EFFORTS  IN  COMPUTER  SECURITY 

Chris  Tomlinson 
Burroughs  Corporation 

Axel  Hvidtfeldt 
Christ ian-Rovsing 

Terry  Cureton 

Control  Data  Corporation 


2:00  ACQUISITION  &  DEVELOPMENT  EXPERIENCE 

SACDIN 

Mauro  Ferdman 

The  MITRE  Corporation 

Communications  Operating  System/NFE 

Gary  Grossman 

Digital  Technology  Incorporated 


WWMCCS  INFORMATION  SYSTEM  COMPUTER  SECURITY 
Larry  Bernosky 

WWMCCS  System  Engineering  Office 


1 


Tuesday,  August  11 

9:15  NBS  COMPUTER  SECURITY  EFFORTS 

Dennis  Branstad 

National  Bureau  of  Standards 


MANUFACTURERS'  EFFORTS  IN  COMPUTER  SECURITY  (Continued) 

Les  DeLashmutt 

Data  General  Corporation 

George  Cox 
■  Intel  Corporation 

Tom  Parker 

International  Computers  Limited 

BoD  Colten  &  Norm  Hardy 
Tymshare 


2:00  DOD  COMPUTER  SECURITY  EVALUATION  CENTER 

George  Cotter,  Acting  Director 

DOD  Computer  Security  Evaluation  Center 

National  Security  Agency 

NON-DOD  1 RUSTED  SYSTEM  NEEDS 

Rein  Turn 

The  Rand  Corporation  (Consultant) 


COMMUNICATIONS  EXPERIENCE 

The  SDC  Communications  Kernel 
David  L,  Golber 

System  Development  Corporation 

The  MITRE  Trusted  Facket  Switch 

Chris  Hisgen 

The  MITRE  Corporation 


5:30  Wine  &  Cheese  Reception 
Washingtonian  Hotel 
(until  7:30  p.m.) 


vi 


Wednesday,  August  12 


9: 15 


2:00 


DEVELOPMENT  EXPERIENCE  UPDATE 
KVM/370 
Tom  Hinke 

System  Development  Corporation 
KSOS-6 
Les  Fraim 

Honeywell  Information  Systems 

KS0S-11 

John  Woodward 

The  MITRE  Corporation 

RESEARCH  AND  DEVELOPMENT  UPDATE 

ACCAT  Guard  &  FORSCOM  Security  Monitor 

Mike  Soleglad 
Logicon 

Security  Model  for  a  Military  Message  System 

Carl  Landwehr 
Naval  Research  Lab 


RESEARCH  AND  DEVELOPMENT  UPDATE  (continued) 

Euclid  &  Verification 
Ian  Griggs 

I.  P.  Sharp  &  Associates,  Ltd 

Evaluation  of  Specification  &  Verification  Systems 

Richard  Platek 
Digicomp  Research 


WRAP-UP 


vi  i 


J 


LIST  OF  HANDOUTS 


REIN  TURN 


TRUSTED  COMPUTER  SYSTEMS:  NEEDS  AND 
INCENTIVES  FOR  USE  IN  GOVERNMENT  AND 
THE  PRIVATE  SECTOR,  JUNE  1981 


v  i  i  i 


w'elcomi ng  Address 

tejrth  Seminar  on  the  DoD  Computer  Security  Initial  ne 
August  10,  1981 

James  H.  Burrows 

Director,  Institute  for  Computer 
Sciences  and  Technology 

1  am  pleased  to  welcome  you  to  the  Fourth  Seminar  on  the  Department  of 
Defense  Computer  Security  Initiative  Program.  As  in  the  past,  the  National 
Bureau  of  Standards  and  the  Institute  for  Computer  Sciences  and  Technolooy 
are  happy  to  collaborate  with  Office  of  the  Secretary  of  Defense  in 
bringing  information  about  trusted  computer  systems  to  users  and  system 
developers.  I  am  told  that  there  is  a  plan  to  hold  a  fifth  seminar  in 
this  series  next  Spring  to  continue  these  valuable  information  exchanges. 

The  program  announcing  this  seminar  also  announced  the  establishment  of 
the  computer  security  evaluation  center  for  the  defense  and  intelligence 
communities  at  the  National  Security  Agency,  a  subject  to  be  addressed  by 
our  di si ii.gui shed  keynote  speaker  this  morning,  we  are  glad  tnat  this 
has  come  to  fruition,  and  hope  that  we  will  be  able  to  continue  to  work 
with  the  evaluation  center  through  the  security  initiative  in  diffusing 
trusted  system  technology  to  the  user  community. 

Computer  security  is  no  longer  an  exclusive  concern  of  the  defense  and 
intelligence  communities.  These  agencaes,  of  course,  have  rigorous 
requirements  for  protecting  the  secrecy  of  data.  However,  as  we  become 
more  dependent  upon  computers  for  handling  financial,  health,  and  other 
critical  information,  techniques  for  assuring  the  integrity  and  reli¬ 
ability  of  computer  systems  become  essential  throughout  the  government 
and  private  sector. 
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Not  only  do  the  defense  agencies  in  the  Federal  Government  need 
of  1 -the- she  1  f  solutions  to  their  security  problems,  but  so  do  the  ALU' 
users  in  the  civil  government  agencies  and  the  private  sector.  NBS  can 
play  a  role  in  getting  information  about  this  needed  technology  to  users 
through  technical  interchanges  such  as  this  seminar,  th- ough  the  publication 
of  technical  reports,  and  through  the  development  of  computer  security 
standards  and  guidelines  when  the  technology  is  appropri ately  developed. 

The  Paperwork  Reduction  Act  of  1980  (P.L.  96-511)  passed  last  year  reflects 
Congress'  concerns  that  computer  security  efforts  be  integrated  into  the 
overall  information  resources  management  concept.  Among  the  responsibilities, 
centered  on  the  Office  of  Management  and  Budget,  in  implementing  the  Act 
are  the  functions  of  developing  and  implementing  policies,  principles, 
standards,  and  guidelines  on  information  disclosure  and  confidentiality, 
and  on  safeguarding  the  security  of  information  collected  and  maintained 
by  the  agencies.  With  its  emphasis  on  planning  for  information  technology 
acquisition  and  use,  the  Act  provides  the  impetus  for  including  essential 
activities  such  as  planning  for  computer  security  into  agency  long-range 
planning  for  information  management  activities. 

I  believe  that  computer  security  is  a  pervasive  problem  that  needs  to; 
level  attention  from  managers,  as  well  as  from  technical  staff.  It  is  a 
problem  that  encompasses  the  entire  information  processing  cycle  from 
intake  of  data  through  the  processing  of  data,  the  delivery  of  the 
information  product,  and  the  storage  of  data.  While  the  need  is  pervasive, 
it  is  also  clear  that  achieving  a  secure  system  is  costly  in  both  time  and 


money. 


Since  the  technology  of  computer  security  is  not  available  in  existing 
computer  systems,  we  have  tried  to  attack  the  problem  of  computer  security 
through  a  variety  of  adininistrati ve  and  management  controls  which  will 
continue  to  be  essential  elements  for  achieving  secure  systems.  Irusted 
system  technology,  however,  offers  promising  capabilities  for  maintaining 
the  integrity  and  reliability  of  critical  systems.  That  assuring  integrity 
and  reliability  is  important  is  evident  in  the  estimates  that  problems 
associated  with  errors,  ommissions,  and  modifications  of  data  occur  ten 
times  more  frequently  than  intentional  disclosures. 

I,  therefore,  stongly  support  this  R&D  and  technology  transfer  effort 
and  hope  that  this  is  a  successful  and  fruitful  seminar. 

1  now  have  the  honor  of  introducing  our  distinguished  keynote  speaker, 
Admiral  Bobby  R.  Inman,  who  has  broad  experience  both  in  the  defense  and 
intelligence  communities.  Admiral  Inman,  a  graduate  of  the  University  of 
Texas,  Austin,  began  his  career  in  the  U.S.  Navy  in  1952.  Since  then,  he 
has  held  the  positions  of  Director  of  Naval  Intelligence,  Vice  Director 
of  the  Dol’cn.a  Intelligence  Agency  for  Plans,  Operations  and  Support,  and 
the  Director  of  the  National  Security  Agency.  He  is  currently  the  Deputy 
Director  of  Central  Intelligence.  Let's  welcome  Admiral  Inman  to  tnr. 
seminar. 
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KEYNOTE  ADDRESS 


COMPUTER  SECURITY  INITIATIVE 
Admiral  Bobby  Inman 

Deputy  Director  of  Central  Intelligence 
Washington,  D.C. 

it  is  a  pleasure  to  welcome  you  to  this  Seminar  and  to  speak  briefly  with 
you  about  computer  security,  the  recent  developments  within  the  Department  of 

Defense  and  the  Intelligence  Community  and  the  challenges  that  lie  ahead. 

As  Dr.  Gerald  P.  Dinneen,  former  Assistant  Secretary  of  Defense  for  Cwi 

defined  at  the  first  of  these  Seminars  two  years  ago,  a  "trusted"  computer 
system  is  one  with  sufficient  hardware  and  software  integrity  to  allow  its  use 
for  the  sin.jl taneous  processing  of  multiple  levels  of  classified  or  sensitive 
i  r.f  orr.at  ion. 

'ne  rit-ec  for  trusted  computer  systems  is  very  real  and  growing  rapidly, 
rectors  influencing  this  need  are: 

the  growing  use  of  automated  information  handling  systems  tnrougnout 
the  uoD  and  the  Intelligence  Cctt.  unity  an:  in  particular  the  linking 
of  these  systems  into  major  networks; 

increasing  requirements  for  controlling  access  to  ccnpartmented  end 
sensitive  information; 

the  requirement  for  broader  dissemination  of  -inf ormation  both  within 
anc  beyond  the  community; 

growing  difficulties  with  obtaining  required  numbers  of  cleared 
personnel,  both  military  and  civilian. 

Despite  continuing  internal  efforts  to  develop  special  purpose  trusted 
systems  for  unique  needs,  we  already  rely  very  heavily  on  the  products  of  the 
computer  industry  to  meet  our  information  processing  requirements,  and  this 
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dependence  will  continue  to  grow  si gni f i cantly  in  the  future.  It  is  therefore 
very  gratifying  to  observe  the  progress  being  made  by  the  computer  industry  in 
applying  computer  security  technology  as  represented  by  the  industry  presenta¬ 
tions  at  this  and  the  previous  Seminars. 

It  is  very  important,  also,  that  the  Department  of  Defense  and  the 
Intelligence  Cotrmunity  develop  sufficient  expertise  to  be  able  to  evaluate  the 
integrity  of  computer  software  and  systems  developed  by  industry  and 
government,  and  that  we  be  able  to  determine  suitable  physical  and 
administrative  environments  for  their  application.  We  have  had  scattered 
efforts  over  the  past  several  years  to  evaluate  specfic  systems  for  specific 
installations.  But  these  efforts  have  always  been  more  or  less  ad  hoc,  and 
because  of  the  extensive  technical  background  required,  expensive  to  carry  out. 

I  am  very  pleased  therefore  to  announce  today  the  establishment  of  a 
Computer  Security  Technical  Evaluation  Center  for  the  Department  of  Defense  and 
the  Intelligence  Community  at  the  National  Security  Agency.  Last  fall,  as 
Director  of  NSA,  I  enthusiastically  endorsed  the  establishment  of  this  Center 
at  NSA  as  a  now  and  separate  function.  I  am  very  pleased  with  the  progress 
being  made  in  setting  up  the  Center  and  1  remain  strongly  committed  to  its 
success . 

I  would  like  to  make  several  observations  about  the  Center  and  some  of  its 
relationships: 

-  Because  the  private  sector  computer  manufacturing  community  is  the 
primary  source  of  ADP  systems,  the  Center's  role  will  be  to  work 
with  the  manufacturers,  deriving  as  much  system  integrity  as  possible 
from  industry  developed  systems.  This  is  a  rather  sharp  contrast  to 
the  NSA's  more  traditional  cormunications  security  role  where  the 
government  has  the  dominant  technical  role. 
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The  Center  will  have  a  difficult  task  developing  procedures  which 
assure  protection  of  sensitive  portions  of  a  system  which  the 
government  does  not  own.  Simply  classifying  security  related 
portions  of  a  system  built  by  industry  won't  work  since  the  govern¬ 
ment  represents  such  a  small  portion  of  the  overall  market  that  the 
manufacturers  may  well  decide  not  to  sell  to  the  government  rather 
than  accepting  the  limitations  imposed  by  classification.  This, 
in  the  end,  might  lead  to  a  highly  undesirable  situation  where  private 
sector  users  (e.g.,  banks,  insurance  companies)  have  higher  integrity 
systems  than  the  government. 

But  sensitive  portions  of  systems  and  the  known  vulnerabilities 
that  remain  must  be  protected,  in  the  interests  of  both  the  government 
and  the  manufacturers.  It  is  quite  likely  therefore  that  the  most 
sensitive  portions  of  the  government's  analyses  will  be  both  classified 
and  proprietary  to  the  manufacturer.  Careful,  reasoned  interaction 
between  the  government  and  industry  will  be  needed  to  work  out 
suitable  working  relationships. 

The  Center  will  act  in  the  interests  and  for  the  benefit  of  the 
Department  of  Defense  and  the  Intelligence  Cormiunity.  Its  evaluation 
will  not  be  intended  for  use  by  other  than  the  DoD.  It  will  not  make 
general  product  endorsements.  But  as  with  the  Qualified  Products  List 
procedures  (as  prescribed  in  the  DoD  Defense  Acquisition  Regulations), 
the  relative  merit  of  a  system  in  the  hierarchy  of  evaluated  products 
may  be  available  publicly  in  order  to  provide  incentive  and 
encouragement  for  manufacturers  to  develop  trusted  systems  and  private 
sector  users  to  employ  them. 
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Because  of  the  wide  range  of  sensitive  environments  that  exist  for 
information  systems  (ranging  from  privacy  applications  to  compartmenta- 
tion  within  the  Intelligence  Community,  and  from  adjacent  security 
levels  (e.g.,  Secret  and  Top  Secret)  to  full  multi-level  systems 
with  Intelligence  users  and  uncleared  users),  it  will  be  vital  for 
the  Evaluated  Products  List  to  offer  a  range  of  technical  categories 
and  appropriate  environments  for  specific  systems.  The  approach  of 
establishing  levels  of  technical  integrity  which  has  evolved  from  the 
work  of  the  Computer  Security  Initiative  indicates  the  kinds  of 
distinctions  which  will  be  made  in  evaluating  systems.  A  range  of 
suitable  environments  is  possible  with  trusted  systems  because  the 
security  accreditation  of  ADP  systems  depends  upon  i !i  of  the 
aspects  of  the  total  system.  The  accreditation  of  a  system  to  serve 
users  cleared  at  both  the  Secret  and  the  Top  Secret  level  is  not  as 
difficult  a  problem  as  extending  the  use  of  such  a  system  to 
uncleared  users  as  well.  The  Department  of  Defense  is  now  using 
Multics  in  such  a  limited  environment  serving  both  Secret  and  Top 
Secret  cleared  users.  The  Evaluated  Products  List  should  provide 
guidelines  for  implementing  this  type  of  operation  where  sufficient 
technical  integrity  of  software  products  can  be  demonstrated. 

Finally,  I  would  like  to  say  that  the  establishment  of  an  Evaluation 
Center,  important  as  it  is,  must  not  be  viewed  as  providing  by  itself 
the  long  sought  answer  to  the  computer  security  problem.  Within  the 
Department  of  Defense  and  the  Intelligence  Community,  system  builders 
will  have  to  become  aware  of  and  properly  employ  the  procedures  for 
development  of  trusted  system  applications.  The  Services  and  Defense 


Agencies  are  being  encouraged  to  establish  or  enhance  their  own 
technical  security  test  and  evaluation  capabilities  to  ensure 
widespread  use  and  availability  of  trusted  computer  systems.  The 
computer  manufacturing  community  must  work  closely  with  the  Center 
and  these  Service  organizations  to  ensure  that  reasonable  products 
are  available  for  use  in  sensitive  applications. 

In  conclusion,  1  would  like  to  restate  my  awareness  of  the  importance  of 
this  problem  area,  my  enthusiasm  for  the  establishment  of  the  Evaluation 
Center,  and  my  deep  and  continuing  interest  in  its  success.  1  encourage  you  to 
participate  fully  in  this  Seminar,  ask  the  tough  questions,  learn  all  you  can, 
and  then  go  out  and  apply  what  you  have  learned  so  that  we  may  all  have  trust¬ 
worthy  computers  in  the  very  near  future. 


IMfROOUCTORY  COMMEMTS 


STEP'IEM  T.  WALKE R 
DIRECTOR  l M FORMAT iOM  SYSTEMS 
OFFICE  (F  DEPUTY  IJMDER  SECRET1RY  0"  DEFENSE  (C^I ) 


Good  Morning.  It  is  indeed  a  pleasure  to  welcome  you  to  the  fourth  Seminar  on 
the  OoD  Computer  Security  Initiative. 

It  was  just  three  years  ago  that  we  began  the  Computer  Security  initiative  and 
just  two  years  ago  that  we  held  the  First  Seminar  hero  at  MSS.  We  had  two 
major  goals  when  we  started  this  effort  and  l  am  proud  to  announce  that  as  of 
today  I  believe  we  have  accomplished  both  of  them. 

As  I  described  in  my  opening  remarks  at  the  last  Seminal",  our  n.i  jor  external 
objective  for  the  Initiative,  that  of  getting  the  computer  manufacturers 
involved  In  the  development  of  trusted  systems,  had  already  come  a  long  way  as 
indicated  by  the  five  manufacturers  who  described  their  efforts  at  that 
seminar.  This  time,  as  you  glance  at  your  program  you  will  sec  that  we  have 
eight  manufacturers  giving  presentations;  seven  new  ones  including  three 
European  manufacturers  and  one  giving  an  update  from  last  time. 

I  must  admit  that  t  expected  only  two  or  three  manufacturer  presentations  and 
as  Pete  Tasker  and  1  were  working  out  the  program  we  had  the  pleasant  task  of 
frequently  shuffling  the  program  as  more  manufacturers  accepted  our  invitation 
to  speak. 

I  think,  it  is  obvious  from  the  number  and  variety  of  manufacturers  represented 
today  and  at  the  last  Seminar  that  there  is  a  strong  interest  in  computer 
security  and  in  trusted  computer  systems  in  the  US  and  international  commuter 
manufacturing  community.  This  external  interest  is  most  gratifying. 

Eut  just  as  exciting  to  me  at  least  is  the  progress  we  have  made  to  satisfy 
the  major  internal  objective  of  the  initiative.  At  the  last  Seminar  I  hinted 
that  within  a  year  there  would  be  a  technical  integrity  evaluation  process  in 
being  to  serve  the  DoD. 

In  fact,  as  Admiral  Inman  has  just  announced,  that  goal  has  been  met  with  the 
establishment  of  the  DoD  Computer  Security  Evaluation  Center  at  MSA.  The 
Deputy  Secretary  of  Defense  made  it  official  as  of  January  1,  lFl  and  MSA  has 
been  hard  at  work  pulling  all  the  necessary  pieces  together  to  get  the  Center 
functioning.  Tomorrow  afternoon  you  will  hear  a  status  report  on  the  Center 
from  Mr.  George  Cotter  of  MSA. 

i  am  personally  very  excited  and  pleased  with  our  progress  in  just  three 
years.  it  is  clear  to  me  that  the  time  was  right  for  what  we  have  tried  to 
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do.  Mv  person.il  thinks  to  everyone  who  his  helped  mike  this  possihl  •.  I 
believe  that  the  combination  of  rapidly  growing  interest  on  th  ■  part  of  the 
computer  manufacturers  and  the  existence  of  a  hob  evaluation  capability  will 
profoundly  influence  the  integrity  of  computer  systems  in  the  very  near  t<T:a 
and  from  now  on. 

ft  is  vital  that  we  start  to  take  advantage  of  this  improvement  as  soon  as 
possible.  In  just  n  minute,  l  would  like  to  propose  a  challenge  to  both  the 
computer  manufacturers  and  the  computer  users  both  in  this  audience  and  beyond. 

Let  me  first  describe  a  particular  situation  as  I  see  it  in  right  now. 

Over  five  years  ago  the  \ir  Force,  after  extensive  testing  an  1  evaluation, 
installed  a  Honeywell  MULT1CS  System  at  the  Data  Services  Center  in  the 
Pentagon.  That  syst-em  has  successfully  operated  in  a  Top  Secret  environment 
with  some  users  cleared  only  for  Secret  access  for  several  years.  It  is  a 
general  purpose  system  being  used  for  all  kinds  of  programming  and 
administration  support  to  the  \v. 

I  am  not  recommending  that  everyone  go  out  and  buy  a  MTLTLCS  System  to  satisfy 
all  their  needs.  But  as  t  review  the  efforts  of  the  many  manufacturers  that  1 
have  talked  with  lately,  l  realize  that  there  is  a  real  potential  for  a  number 
of  systems  with  integrity  similar  to  M’lLTlCS  to  be  available  in  the  not  so 
distant  future. 

So  what,  you  say’.  \  Top  Secret-Secret  environment  is  not  fully  multilevel 
secure.  I  can't  have  the  highest  levels  of  sensitive  data  on  ny  system  with 
unclassified  users  so  it  hasn't  solved  my  problem. 

Tn  reality  though,  not  very  many  applications  require  a  system  to  operate  over 
anything  like  the  full  range  of  sensitive  information.  This  afternoon  you 
will  hear  about  the  computer  security  aspects  of  the  UWMCCS  Information  System 
Modernization  effort,  perhaps  the  largest,  highly  sensitive  computer  svstom 
upgrade  that  the  nob  will  perform  this  decade.  There  are  multilevel  security 
problems  throughout  W1S  but  as  you  will  hear,  the  requirements  exist  over  a 
reasonable  range  of  sensitivity  levels,  not  necessarily  over  the  full  range  of 
possible  levels. 

if  one  couples  the  fact  that  tlu*  manufacturers  could  soon  develop  trusted 
systems  with  Integrity  levels  similar  to  MHLTICS  and  the  realization  th’.t  ininy 
of  our  security  requirements  can  be  met  by  systems  that  operate  over  a  limited 
range  of  sensitivity,  it  is  possible  to  sec  how  solutions  to  at  least  these 
limited  nppl icat ions  may  ha  forthcoming  very  soon. 

You  may  accuse  me  of  advocating  a  less  then  perfect  solution  hy  what  I've  just 
said.  Far  from  that,  though,  l  am  advocating  seeking  a  reasonable,  useful 
solution  prior  to  seeking  the  perfect  solution.  Indeed  if  we  do  not  mko 
serious  attempts  to  crawl  before  we  run  here,  we  very  1 i ke 1 v  will  never  get 
anywhere  near  that  perfect  solution. 


Vow  back  to  my  challenge.  I  would  like  to  challenge  th"  users  in  this 
audience  to  seriously  review  their  needs  for  trusted  computer  systems  and 
determine,  as  harry  Hernosky  has  for  the  WWMCCS  information  System,  which 
needs  could  be  met  by  systems  able  to  operate  over  limited  sensitivi tv 
ranges.  To  the  extent  that  you  can  do  this,  I  strongly  urge  you  to  convey 
this  information  to  your  local  computer  manufacturers  representatives  to  help 
motivate  them  to  develop  systems  to  meet  your  needs,  and  tlu-n  get  involved  in 
the  evaluation  of  potential  systems  for  your  application. 

I  would  similarly  challenge  all  the  manufacturers  in  the  audience  to  study 
what  has  been  done  to  date,  understand  the  security  design  of  systems  like 
MULTICS,  Kernolized  Secure  Operating  System  (KSOS)  and  -lernelized  VM  170 
System  (KVMl  and  incorporate  these  ideas  into  your  product  lines,  quickly. 

More  and  more  users  are  beginning  to  realize  not  only  that  they  need  improved 
integrity  within  their  computer  systems  but  also  that  it  is  possible  to  build 
systems  with  these  improvements,  and  that  they  can  begin  to  demand  such 
features.  ,\s  you  can  tell  from  the  manufacturers  participation  here,  at  least 
some  of  your  competitors  are  taking  this  seriously. 

We've  come  a  long  way  in  the  last  few  years.  We've  completed  the  first  ton  >h 
phase  of  the  Initiative,  getting  the  various  pieces  in  place.  N'ow  it's  time  to 
move  into  phase  two.  This  will  involve  a  lot  of  work  by  the  manufacturers  and 
you  the  users  have  the  opportunity  and  the  responsibility  to  get  involved. 

I  know  by  your  being  here  that  you  are  interested.  T  challenge  you  to  get 
seriously  involved. 

i  would  now  like  t-  summarize  the  activities  of  the  Initiative  on  the  n-’xt.  few 
slides. 
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ON  JANUARY  1,  1981  THE  SECRETARV  OF  DEFENSE 
ASSIGNED  RESPONSIBILITY  FOR  COMPUTER 
SECURITY  EVALUATION  FOR  DOD  TO  THE  DIRECTOR, 
NATIONAL  SECURITY  AGENCY. 
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SUMMARY 


EXPLOIT  A  SIMPLE  AND  USEFUL  POLICY 
TO  REDUCE  THE  EFFORT  OF 
CONSTRUCTING  A  SECURE  LOCAL 
NETWORK 
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CR80-A  Fault  Tolerant  Computer  for  Implementation  in  Secure  Systems 

Asbjtfrn  Smitt 

Head  of  Research  and  Development 
Christian  Rovsing  A/S,  Ballerup,  Denmark 

1.1  General 

Christian  Rovsing  A/S  with  the  CR80  MAXIM  and  FATOM  virtual  machines 
has  introduced  a  new  and  powerful  architecture  for  implementing  secure 
systems  on  a  ultra-reliable,  easy  to  maintain  and  modular  fail  safe  computer. 
The  high  speed  memory  mapped  multiprocessor  computers  have  been  designed 
to  provide  modular  growth  in  processing  power  and  memory  requirements  to 
cope  economically  with  the  requirements  of: 

•  General  purpose  computer  systems 

•  Packet  switches 

•  Message  switches 

•  Control  and  Command  Information 

•  Concentrators 

•  On-line  systems 

•  Terminal  systems 

•  Front  end  processors 

The  illustration  overleaf  shows  that  the  CR80  FATOM  computer  tightly 
couples  up  to  16  Processing  Units  (Multiprocessors)  together  via  the  S-NET, 
and  that  each  peripheral  connects  through  individual  channels  to  two 
Processing  Units,  one  channel  being  the  active  connection  for  a  connected 
peripheral,  the  other  the  back-up  connection.  Also  it  is  seen  that  the  CR80 
MAXIM  (Memory  mapped  Maxi-computer)  is  the  single  Processor  Unit,  non- 
redundant  subset  of  the  CR80  FATOM  (Fault  Tolerant  multiprocessor) 
otherwise  they  have  identical  high  performance  characteristics. 

The  CR80  FATOM  fault  tolerant  computer  differs  from  other  computers 
(large,  medium  or  small)  in  that  it,  based  on  a  unique  distribution  of  its 
memory  providing  nearby  unlimited  processing  power,  up  to  50  Million 
instructions  per  second  (MIPS)  together  with  minimum  added  hardware  to 
achieve  its  "self  repair"  features  and  256  Mega  word  maximum  memory  si/.e. 
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Extensive  hardware  checks  has  been  incorporated  throughout  the  CR  80 
architecture,  supporting  integrity  and  security  in  execution  of  both  application 
and  system  programs,  ensuring  that  erroneous  interaction  among  users,  and 
with  the  system  software,  are  prohibited.  This  is  extremely  important  during 
software  maintenance  and  development,  once  a  fault  tolerant  system  has  been 
brought  operational,  as  well  as  facilitating  the  initial  software  development 
and  debugging. 

The  CR80  architecture  and  DAMOS  system  software  supports  modularily  the 
total  spectrum  of  virtual  memory  machines,  from  the  0. 7-3.0  MIPS  MAXIM 
multiprocessor  computer  with  one  or  more  CPUs,  up  to  the  50  MIPS,  N+l 
redundant  FATOM  computer,  incorporating  the  cost  effective  approach  of  only 
having  1  single  spare  unit,  capable  of  backing  up  for  any  of  N  working  units). 
The  CR80  can  be  upgraded  in  the  field,  often  without  stopping  operational  use, 
due  to  its  on-line  maintenability  and  unique  galvanic  isolation  between  system 
elements  at  the  card-magazine  level. 

A  CR80  Processor  Unit  (PU)  constitutes  either  a  uni-  or  multiprocessor 
computer  with  from  1  to  5  CPUs  (.7  to  3  MIPS).  The  CR80  FATOM  connects  up 
to  16  Processor  Units  (PUs)  together  via  the  extremely  fast  S-NET  (up  to  512 
Mbit/sec.)  into  a  tightly  coupled  multicomputer  with  up  to  50  MIPS  capability. 
In  addition  all  lower  levels  of  input/output  processing  is  distributed  to  the  I/O 
controllers  (peripheral  processors)  in  the  Channel  Units  (CU),  this  further 
enhances  the  CR80  above  the  simple  accumulated  processing  power  of  the 
CPUs. 

The  I/O  Controllers  (peripheral  processors)  communicates  with  PUs  through 
one  port  of  the  triple  ported  controller  memory,  the  two  other  ports  allowing 
for  this  memory  being  part  of  the  address  space  of  two  processing  units  (PUs), 
which  ensure  an  alternative  path,  in  case  of  a  Processing  Unit  (PU)  failure. 


The  CRSO  computers  also  gain  their  strength  from  very  fast  intelligent 
multiplexed  Direct  Memory  Access  (DMA)  channels  between  the  distributed 
memory  in  PUs  and  CUs  and  that  the  imbedded  channel  processors  (S-NET  & 
DATA  CHANNEL)  with  minimum  interruption  of  the  CPUs  autonomeously 
handle  and  ensure  the  integrity  of  hundreds  of  simultaneous  active  logical 
channels  between  programs  and  processes. 

The  CR80  FATOM  basic  system  philosophy  is  to  achieve  N+I  redundancy  on  all 
levels,  both  processors  and  I/O  controllers.  A  unified  system  approach  to 
software  in  a  redundant  system,  relieving  application  software  as  far  as 
possible  of  mechanisms  and  functions  necessary  for  fault  tolerance,  moving 
these  to  the  system  S/W.  The  CR80  FATOM  Computer  thus  is  designed  to  have 
no  single  points  of  failure  on  a  system  basis,  this  includes  all  parts  of  the 
system:  Processors,  busses,  I/O  devices,  power  supply,  cooling  and  software  in 
order  to  achieve  a  continously  available  no-break  computer.  The  on-line 
maintenance  features,  allows  any  failed  module  to  be  exchanged  and  tested, 
without  interrupting  system  operation. 

Also  the  CR80  modular  packaging  and  integration  system,  ensures  the 
capability  for  expansion  of  a  CR80  FATOM  Computer  to  virtually  any  physical 
size,  using  only  a  few  standard  types  of  modules  and  cables,  as  well  as 
achieves  the  cost  efficiency  of  both  the  single  and  fault  tolerant  CRSO 
Com  puters. 


As  an  introduction  to  the  features  of  the  CR80  memory  mapped  PU  a  brief 
discussion  of  the  CRSO  Processor  Unit  Logical  Organization,  shown  overleaf  is 
given. 

Interconnection  of  the  PU  modules  is  performed  by  means  of  two  parallel 
transfer  busses,  the  (Processor  Bus)  and  the  (Channel  Bus)  implemented  as  two 
backplane  printed  circuit  boards.  The  busses  have  identical  electrical  and 
timing  specifications  with  the  following  characteristics:  transfer  rate  up  to  4 
mega  word  per  second  (16  bits  +  2  parity  bits),  addressing  of  1  mega  word  as 
word  or  byte.  The  Processor  Bus  performs  as  transfer  bus  for  the  Central 
Processor  Units  (CPUs),  while  the  Channel  Bus  performs  as  transfer  bus  for 
the  Channel  Bus  modules  (DMAs). 

The  central  processor  units,  CPUs,  are  general  purpose  processor  units  with  a 
word  length  of  16  bits  and  the  ability  to  address  64K  word  of  instruction  and 
64K  word  of  data.  All  data/instruction  transfer  performed  by  the  CPU  are  via 
the  processor  bus  and  the  memory  MAP  to  the  memory.  Physically,  the  CPUs 
and  the  memory  MAP  are  connected  to  the  same  Processor  Bus,  but  logically 
the  CPUs  recognize  the  MAP  as  being  located  between  the  memory  and  the 
CPU. 

The  function  performed  by  the  memory  MAP  is  to  expand  the  addressable 
memory  area  to  16  mega  word  of  which  1  mega  word  can  be  located  in  the  PU 
as  fast  access,  local  storage,  while  the  remaining  15  mega  word  can  be  located 
on  the  data  channel.  Besides  the  address  translation,  the  MAP  also  includes 
memory  read/write  protection,  the  protection  can  be  performed  individually 
for  each  IK  page  of  the  memory. 
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The  functions  performed  by  the  MAP  on  the  Processor  Bus  transfers  are  also 
performed  on  all  Channel  Bus  transfers,  meaning  the  Channel  Bus  Modules  can 
access  the  complete  16  mega  word  memory  area,  but  only  the  areas  which  are 
not  protected. 

Beside  the  address  translation  describ'd  above,  the  MAP  module  also  includes 
the  Channel  direct  memory  access  (DMA)  function,  interrupt  preprocessing 
and  Data  Channel  Interface. 

The  DMA  is  used  for  blcok  transfer  between  shared  memory  with  peripheral 
Controllers  and  PU  local  memory  and  is  under  control  of  the  Input/output 
system  software. 

The  interrupt  preprocessing  performed  ensures  that  only  interrupts  (CPU  or 
I/O)  with  sufficient  priority  will  cause  a  context  switch  in  one  of  the  CPUs, 
while  all  other  interrupts  will  be  queued  by  the  MAP,  until  the  CPU  status 
allows  service  of  them. 

Transfer  on  the  Data  Channel  will  be  performed  by  the  memory  MAP  when  the 
addressed  location  is  not  within  the  PU  Local  Main  Memory  addressing  space  (1 
Mw). 

Security  is  supported  by  means  of  memory  access  protection  and  division  of 
instructions  into  three  privilege  classes. 

The  CPU  has  16  states  of  which  one  (state  0)  is  a  user  state  and  15  (states  1 
through  1 5)  are  system  states.  In  user  state  only  not  privileged  instructions 
may  be  executed.  Medium  privileged  instructions  can  be  executed  at  all 
system  states  while  the  most  privileged  instructions  are  reserved  for  execution 
at  system  state  15. 

Attempt  to  illegally  execute  a  privileged  instruction  in  user  state  or  system 
states  1  through  14  causes  a  local  interrupt,  upon  which  the  CPU 
automatically  envokes  a  supervisor  routine. 
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The  CPU  state  is  changed  by  means  of  the  MON_instruction  which  is  used  to 
activate  system  procedures. 


i 

I 

1 
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CR80  Security  Mechanisms 


The  inherent  logical  and  physical  separation  of  programs  and  data  in  the  CR8Q 
architecture  is  well  suited  for  preventing  unauthorized  access  to  data  and 
programs  and  for  preventing  non-intended  modification  of  programs. 

The  objectives  of  the  protection  mechanisms  in  the  CR80  are: 

to  protect  data  belonging  to  a  process  against  unauthorized  modification 
by  other  processes  and  against  not  intended  reading; 

to  protect  programs  against  modifications,  and, 

to  prevent  unauthorized  execution  of  programs  and  system  resources 

to  prevent  processes  from  monopolizing  the  processor. 

Security  is  supported  by  means  of  memory  access  protection  and  division  of  instructions 
into  three  privilege  classes. 

The  CPU  has  1 6  states  of  which  one  (state  0)  is  a  User  state  and  1  5  (states  1  through 
15)  are  System  States. 

Higher  stateshavemore  privileges  thanlowerstates.lnuserstateonlynotprivileged 
instructions  may  be  executed.  Medium  privileged  instructions  can  be  executed  at 
all  system  states  while  the  most  privileged  instructions  are  reserved  for  execution 
at  system  state  15. 

Attempt  to  illegally  execute  a  privileged  instruction  in  user  state  or  system 
states  1  through  14  causes  a  local  interrupt,  upon  which  the  CPU 
automatically  envokes  a  supervisor  routine. 

The  CPU  state  is  changed  by  means  of  the  MON_instruction  which  is  used  to 
activate  system  procedures. 

In  addition  to  the  memory  protection  provided  in  USER  STATE  by  the 
MEMORY  MAP,  each  of  the  system  states  has  its  own  memory  bound  register. 

Only  data  memory  locations  below  or  equal  to  this  boundary  value  may  be 
modified  while  all  data  memory  locations  available  might  be  read  in  SYSTEM 
STATE. 
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The  Memory  Map  protection  mechanism  which  is  active  in  user  state  is 
implemented  by  means  of  two  access  control  bits  for  each  1  Kw  page  in 
memory.  The  protection  values  are: 

access 

control 

bits: 

00  Page  absent 
01  Full  access 

10  Read  only 

1 1  No  access 

As  will  be  seen  in  the  following  ail  non-privileged  (USER  STATE)  memory 
accesses  (both  from  CPU's  and  DMA's)  go  through  the  Memory  Map,  and  are 
checked  by  hardware  not  to  violate  the  protection  value.  In  the  system  state 
full  access  (read  or  write)  is  granted  irrespective  of  the  protection  value. 

If  a  not  allowed  access  is  attempted,  the  transfer  is  terminated  without 
sending  the  physical  address  to  the  memory,  and,  a  transfer  error  is  signalled 
from  the  Memory  Map. 

The  "Page  absent"  condition  is  used  to  invoke  the  demand  paging  feature  of 
DAMOS.  It  indicates  that  the  accessed  page  is  not  resident  in  main  memory  (or 
not  mapped  in),  and  will  lead  to  suspension  of  the  process  until  the  page  has 
been  loaded  into  memory  or  relocated. 
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Security 

The  CR80  operating  system  DAMOS  offers  comprehensive  data  security 
features.  A  multilevel  security  system  ensures  that  protected  data  is  not 
disclosed  to  unauthorized  users  and  that  protected  data  is  not  modified  by 
unauthorized  users. 

All  memory  allocatable  for  multiple  users  is  erased  prior  to  allocation  in  case 
of  reload,  change  of  mode,  etc.  The  erase  facility  is  controlled  during  system 
generation. 

DAMOS  is  specified  using  the  formal  notation  of  the  Wienna  development 
method  with  the  intention  of  making  formal  verification  possible. 

The  security  system  is  based  on  the  following  facilities: 

a.  Hardware  supported  user  mode/privileged  mode  with  16  privilege 
levels.  Priviliged  instructions  can  be  executed  only  when  processing 
under  DAMOS  control. 

b.  Hardware  protected  addressing  boundaries  for  each  process. 

c.  Non-assigned  instructions  will  cause  a  trap. 

d.  Primary  memory  is  parity  protected. 

e.  Memory  bound  violation,  non-assigned  instructions,  or  illegal  use  of 
privileged  instructions  cause  an  interrupt  of  highest  priority. 

f.  The  hierarchical  structure  of  DAMOS  ensures  a  controlled  use  of 
DAMOS  functions. 

h.  A  general  centralized  addressing  mechanism  is  used  whenever 
objects  external  to  a  user  process  are  referred  to. 
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A  general  centralized  access  authorization  mechanism  is  employed. 


Centralized  addressing  capabilities  and  access  authorization  are  integral  parts 
of  the  security  implementation.  User  processes  are  capable  of  addressing 
Kernel  objects  only  via  the  associated  object  descriptor  table.  The  following 
types  of  DAMOS  objects  are  known  only  via  object  descriptors: 

a.  Processes 

b.  Synchronization  elements 

c.  Segments 

d.  Devices 

e.  PUs 

f.  CPUs 

g.  Ports 

The  object  descriptor  forms  the  user  level  representation  of  a  DAMOS  Kernel 
object.  It  contains  the  information  necessary  for  the  Kernel  to  locate  its  low 
level  representation  and  to  ensure  its  security  and  integrity: 

a.  Host  PU 

b.  Object  type 

c.  Object  control  block  index  for  use  by  the  Kernel  to  locate  the 
corresponding  object  control  block. 

d.  A  sequence  number  which  must  match  a  number  in  the  object 
control  block  (to  prevent  reallocated  blocks  from  being  erroneously 
accessed). 

e.  A  capability  vector  specifying  the  operations  which  may  be  perfor 
med  on  the  object  by  the  process  which  has  the  object  descriptor. 
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The  access  right  information  concerning  the  various  DAMOS  objects  is 
retained  in  a  PU  directory  of  object  control  blocks.  Each  control  is  associated 
with  a  single  object. 

When  the  access  right  of  a  process  to  a  segment  is  verified  and  the  segment  is 
included  in  the  logical  memory  space  of  the  process,  the  contents  of  that 
segment  may  be  accessed  on  a  16-bit  word  basis  at  the  hardware  level  subject 
to  hardware  access  checks. 

Authorization  of  access  to  an  object  is  based  on 

•  a  general  security  policy,  and 

•  a  discretionary  access  checking 

The  security  policy  is  based  on  a  multilevel  -multicompartment  security 
system. 

Objects  are  associated  with  a  security  classification  level  for  each  compart- 
kent  (i.e,,  set  of  data  with  the  same  kind  of  information)  and  subjects 
(processes)  are  associated  with  a  security  clearance  level  for  each  compart¬ 
ment.  Both  entities  are  described  in  a  common  type: 

•  the  security  profile 
Discretionary  access  checking  is  based  on 

•  identification  of  access  classes  of  subjects  (processes),  and 

•  statements  of  access  capabilities  for  explicitly  enumerated  access 
classes  of  subjects  vis  a  vis  a  given  object. 

Access  to  an  object  is  authorized  if  the  following  conditions  are  both  fulfilled: 
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•  the  access  operation  requested  is  allowed  according  to  the 
capability  vector  in  the  object  descriptor 

•  the  combination  of  process  security  profile,  object  security  profile 
and  operation  (read  or  write)  agrees  with  the  security  policy. 

The  security  policy  is: 

•  A  process  may  read  from  objects  with  classification  not  higher 
than  that  of  the  process.  An  untrusted  process  may  write  to  objects 
with  classification  not  lower  than  that  of  the  subject. 

•  A  trusted  process  may  write  to  objects  with  any  classification. 

A  process  can  only  obtain  access  rights  (i.e.,  an  object  descriptor)  to  a  DAMOS 
object  in  the  following  ways: 

a.  By  inheritance  from  a  parent  process 

b.  By  creating  the  object. 

c.  By  successful  look-up  in  the  PU  directory. 

Similarly,  a  process  can  only  distribute  access  rights  to  objects  registered  in 
its  object  descriptor  table.  This  may  be  done: 

a.  By  inheritance  when  creating  a  child  process 

b.  By  entering  the  object  into  the  PU  directory  by  a  symbolic  name. 

When  an  object  is  entered  into  the  directory  it  is  specified  by  whom  it  may  be 
looked  up  and  what  capabilities  they  should  have  vis  a  vis  the  object. 

The  object  descriptor  table  and  Security  profile  of  a  process  is  kept  in  a 
memory  which  is  accessible  by  that  process  when  it  is  execul  ng  in  privileged 
mode,  but  protected  against  modification  by  the  process  when  executing  in 
user  mode. 
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DAMOS  SECURITY 


Layered  design 


user  levels 


DAMOS  SECURITY 


Kernel 

•  Directory  functions 

•  Error  processing 

•  CPU  management 

•  Real  time  clock 

•  Process  management 

•  PU  management 

•  Memory  management 

•  PU  service  module 

•  Inter  process  communication 

•  Transfer  module 

•  Device  management 

•  Basic  transport  service 

•  Device  handlers 

L _ _ 
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Objectives: 

Data  security 

•  Protection  of  data  against  disclosure  to 
unauthorized  users 

•  Controlled  update  of  data 

Availability  of  service 

•  Protection  against  denial  of  service 

Measures: 

•  Capability  based  design 

•  Resource  management 
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HW  security  features 

Memory  protection  embedded  in  memory  mapping 

•  16  Privilege  levels 

Each  with  an  associated  memory  boundary 

•  Privileged  instructions 

•  Non-assigned  instruction  codes  trap 

•  Parity  on  memory 
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Access  authorization 

( PROCESS 
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\ 

ACCESS 

CONTROL 
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•  Security  check 

•  Descretionary 

L 

access  right  verification 

J 
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Security  profile 

Defines  a  classification  for  each  of  a  set 
of  compartments 


Type  profile  record 
A  class  min  A  class. .max  A  class 


N  class  min  N  class. .max  N  class 
End: 
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Discretionary  acces  right 
•  Subject  identified  by  a  user  group  identifier 


Object  has  an  acess  control  list 
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Object  descriptor 
Information  contained  in  OP; 

•  Host  PU 

•Object  type  and  subtype 

•  Index  to  object  control  block 

•  Object  control  block  sequence  number 

•  Object  acces  level 

•  Capability  vector 

Object  descriptors  may  be  obtained  via; 


Creation  of  object 
Inheritance  from  parent  process 
Lookup  in  PU  directory 


DAMOS  SECURITY 


Change  of  execution  level 

Change  of  view  (processing  domain) 

•  MON  instruction 

•CALL  instruction 

Only  at  level  1 5 

•  RTM  instruction 

•  RET  instruction  J 

•  Interrupt 

•  Interrupt 

•  RTI 

L 

•RTI 
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[SLIDE:  CDC  Logo] 

It  is  a  pleasure  for  me  to  represent  Control  Data  at  this  seminar.  We 
have  been  observing  the  activities  of  the  DoD  Computer  Security 
Initiative  for  some  time,  and  are  impressed  with  your  progress.  Until 
recently,  our  pa rt ici pat  ion  in  the  Initiative  has  been  silent.  For 
the  most  part,  this  has  been  due  to  the  largely  theoretical  or 
experimental  nature  of  the  material  presented.  However,  the 
Initiative  has  given  us  an  opportunity  to  look  at  our  own  experiences 
in  computer  security  from  another  viewpoint.  We  can  now  see  the 
pa ra 1 le Is* and  principles  common  to  both  the  theoretical  work  and  our 
experience  as  practitioners  of  computer  security.  The  message  we 
would  like  to  share  with  you  today  is  that  we  at  last  see  a 
conve  rgence  between  the  theory  and  practice. 


[SLIDE:  Topics] 

To  begin,  I  must  start  with  what  Control  Data  is,  and  why  we  are 
involved  in  computer  security.  Then,  I  would  like  to  dispel  a  myth 
about  security  and  performance,  by  relating  that  to  our  unique  machine 
architecture.  Next,  I  will  briefly  describe  how  that  architecture  is 
reflected  in  our  operating  system  design.  A  comparison  of  commercial 
versus  government  security  requirements  will  show  how  we  plan  to  meet 
both.  Another  comparison  of  formal  and  informal  design  methodologies 
will  show  how  we  think  they  are  converging.  Lastly,  I  will  describe 
our  involvement  with  the  DoD  Initiative  and  our  view  of  its  impact  on 
the  industry  as  a  whole. 


[SLIDE:  Control  Data  Reputation] 

What  kind  of  company  is  Control  Data? 

-  Many  of  you  know  Control  Data  is  in  che  large-scale  scientific 
and  engineering  computer  business. 

-  That  is  our  tradition  and  our  legacy,  since  the  company  was 
founded  in  1957  -  since  the  days  of  the  1604  and  the  6600. 
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[SLIDE:  Control  Data  Today) 

But  you  may  not  be  aware  of  the  range  of  Control  Data's  business 
today.  Yes,  we  still  make  super-scale  computers  to>'  our  systems 
business,  but  we  are  also  the  industry's  leading  supplier  of 
peripherals  -  both  OEM  and  plug-compatibles,  in  addition  to  our  owi. 
label.  The  next  time  you  walk  into  a  room  full  of  disks,  there'.'  a 
good  chance  (65%)  that  we  made  them,  since  we  supply  OEM  peripherals 
to  all  but  one  of  the  major  manu f act u r e rs .  We  are  also  deeply 
committed  to  education  with  our  unique  PLATO  system.  PLATO  is  winnin 
acceptance  in  uses  ranging  from  teaching  grade  school  fundamentals,  t. 
training  airline  pilots  and  nuclear  safety  engineers.  But  it  is  it. 
Data  Services  that  we  are  the  world-wide  leader. 


[SLIDE;  DATA  SERVICES) 

Our  Data  Services  Company  operates  both,  commercial  and  scientific  da  t 
centers  around  the  world,  around  the  clock.  Its  a  more  than  [jail 
billion  dollar  business,  reaching  from  Main  Street  to  Wall  Street. 

And  -  whether  it  is  a  small  businessman  dealing  with  our  Service 
Bureau  Company  in  Cleveland  -  or  an  engineering  t  i  rm  dealing  with  .'■!» 
CYBERNET  Services  in  Copenhagen  -  the  two  questions  we  always  get  a-. 


[SLIDE.  DS  Customers  Ask] 

"How  much  will  it  cost?"  and 
"How  secure  will  my  data  be?". 


[SLIDE:  Security  (1)] 

Clearly,  security  is  a  customer  concern,  and  for  Control  Data  it  is  a 
hard-nosed,  hard-headed  business  need.  Tt  is  here  that  Control  Data 
learned  about  conputer  security  in  a  day-to-day  pragmatic  way.  Mo¬ 
have  been  addressing  that  need  for  more  than  20  years,  since  the 
beginnings  of  Data  Services. 

Now,  Data  Services  is  a  large  chunk  of  our  business,  in  fact  they  a-e 
our  largest  Systems  "customer".  Their  needs  have  a  major  impact  on 
system  design  and  development.  Simply  put  -  Security  has  been 
essential  to  our  largest  system^  marketplace  for  more  than  20  years. 
That's  why  Control  Data  nas  been  involved  in  computer  security.  We 
will  have  to  look  at  the  data  services  environment  to  see  how  it 
relates  to  computer  security. 
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[SLIDE.  Timesharing  Environment] 

from  a  security  viewpoint,  it  is  the  timesharing  environment  where  the 
needs  are  greatest.  The  first  need  c  f  course,  is  to  simply  keep  it 
running,  since  users  have  little  patience  for  system  downtime.  That 
requires  a  good  deal  of  system  integrity,  in  the  first  place.  by- 
definition,  timesharing  means  multiple  users  sharing  system  resources. 
Those  resources  and  the  users'  data  are  real  and  tangible  assets  which 
must  be  protected.  Then,  resources  have  to  be  controlled  so  that  all 
may  share  equitably,  and  if  you  want  to  get  paid,  they  have  to  be 
accounted  for.  Finally,  users  have  to  be  kept  sepe^ate,  since  *  hey 
might  be  competitors. 

Control  Data  met  those  needs  by  developing  a  system  specifically 
designed  for  the  timesharing  environment.  Over  time,  security  tl.vws 
were  discovered  and  corrected,  and  new  security  mechanisms  evolved 
into  the  system  design.  We  built  up  a  great  deal  of  practical 
experience  with  that  system,  and  that  system  evolved  into  our  s'anujr.] 
system  of  today.  But  it  wasn't  until  the  DoD  Initiative  that  -,e  tally 
recognized  ttie  unique  advantages  of  the  CYBER  170  architecture 
regarding  security. 

What  is  so  unique  about  the  CYBER  170  architecture  and  security?  !.,<.• 
answer  in  a  word  is  -  Per_fjO_rnia nee.  There  seems  to  be  a  growing 
supposition  in  the  industry,  that  security  can  only  be  obtained  at  the 
expense  of  performance.  We  would  like  to  dispel  that  myth,  by  showing 
how  the  CYBER  architecture  and  hardware  can  provide  security  without 
penalizing  performance.  To  understand  why,  we  have  to  first  examine 
the  relationship  between  security  and  performance,  and  then  how  that 
relates  to  design. 


[SLIDE:  Performance] 

When  considered  in  a  broad  sense,  performance  over  the  long  term 
requires  both  speed  and  endurance  -  that's  why  the  Indianapolis  500  is 
so  tough .  It  isn't  worth  much  to  be  the  fastest  in  the  race,  if  you 
can't  keep  it  running  long  enough  to  finish.  In  computing  terms, 
endurance  is  a  combination  of  reliable  hardware  and  software,  and  the 
total  system's  ability  to  recover  when  something  does  break. 


[SLIDE:  Security  (2)] 

In  that  sense,  the  concept  of  integrity  as  a  security  requirement,  is 
just  another  way  of  describing  endurance  for  performance.  Thus  the 
emphasis  on  system  integrity,  as  described  in  these  DoD  Seminars,  is 
consonant  with  our  experience  in  computer  security.  That's  one  sign 
of  a  convergence  between  the  theory  and  practice. 

Given  that  endurance  and  integrity  are  just  different  views  of  the 
same  set  of  requ i rements ,  then  those  hardware  and  software  features 
which  contribute  to  the  endurance  of  a  system  are,  in  tact, 
contributing  to  both  performance  and  security.  Here's  another  way  to 
look  at  it. 
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[SLIDE:  Implementation] 

From  this  viewpoint,  we  can  see  how  security  and  performance  should  be 
mutually  benefical  -  synergistic  if  you  will  -  rather  than  conflicting 
goals.  How  these  features  are  implemented,  -  and  which  are  in 
hardware  -  is  where  conflicts  arise.  If  security  features  must  be 
implemented  in  software  -  at  the  expense  of  performance,  -  then  the 
software  designer  is  forced  to  make  a  tradeoff  decision. 

Historically,  the  choice  has  been  in  favor  of  performance,  simply 
because  that's  what  sold  computers.  But  that  tradeoff  is  beginning  tc 
shift  the  other  way  now. 

[SLIDE:  Hardware  Security/Perf ormance] 

Specifically,  there  are  four  key  hardware  characteristics  which  are 
contribute  to  both  performance  and  security: 

o  Machine  Architecture, 

o  Memory  Protection, 

o  Context  Switching,  and 

o  Reliability  Features. 

Let's  look  at  each,  beginning  with  the  a rch i t ect ur e . 


[SLIDE:  Architecture] 

This  is  the  general  architecture  of  the  Control  Data  Cyber  170  series 
computers.  What  is  unique  in  this  block  diagram  is  the  Peripheral 
Processor  Units  (PPUs)  in  the  middle.  These  are  up  to  20  separate, 
independent  computers,  which  operate  concurrently  with,  but 
independent  of,  the  Central  Processor.  Note  also  that  all  I/O 
operations  must  be  performed  by  the  PPUs.  Already  we  see  the 
principle  of  separation  of  functions  implemented  in  hardware.  I'll 
come  back  to  the  performance  aspects  of  thi»B  later.  Let’s  just  see 
how  that  architecture  is  reflected  in  the  system  design. 


[SLIDE:  System  Layout] 

I  must  explain  that  only  system  software  executes  in  the  PPUs.  In 
fact,  most  of  the  operating  system  consists  of  modules  to  be  executed 
in  a  peripheral  processor.  The  PPUs  also  have  primary  control  of  the 
operating  system.  The  one  at  the  top,  labeled  MTR  (Monitor)  is  the 
real  boss  of  the  system.  The  executive  shown  in  central  memory  is 
just  a  fast  assistant  to  MTR.  User  jobs  also  reside  in  central  memory 
and  only  execute  in  the  CPU.  Again,  we  see  a  separation  of  functions. 
When  a  user  program  requests  I/O,  or  other  services,  from  a  PPU,  it 
validates  the  request  and  performs  the  operation  completely 
independent  of  the  CPU.  The  CPU  program  is  thus  isolated  from  I/O 
operations  and  qannot  directly  participate  in  error  handling  and  so 
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on . 

On  performance,  it  should  be  noted  that  concurrent  operations  in  the 
PPUs  also  means  that  the  software  designer  need  not  make  a  tradeoff 
between  security  and  performance.  While  a  PPU  module  is  laboriously 
checking  parameters  or  validating  a  user's  authority  to  perform  an  I/O 
function,  the  CPU  can  be  producing  useful  computations  for  another 
user.  This  hardware  separation  pays  off  directly  in  performance,  and 
at  the  same  time,  establishes  a  solid  base  for  security. 

Let's  move  on  to  memory  protection.  Actually,  memory  protection  also 
starts  with  the  arch i tecture.  What  better  isolation  can  there  be  than 
between  physically  separate  memories?  Each  Peripheral  Processor  has 
its  own  independent  memory,  separate  from  the  other  PPUs,  and  more 
important  -  from  Central  Memory  where  users  must  reside.  Again, 
hardware  design  provides  the  separation  and  isolation  necessary  for 
secur i ty . 

But  notice,  there  are  some  system  tables  and  software  sharing  central 
memory  with  the  user  jobs.  Here  separation  is  maintained  by  the  CPU 
memory  protection  scheme. 


[SLIDE:  Memo ry  Protection] 

This  scheme  is  simply  a  base  and  bounds  hardware  register  pair.  The 
Reference  Address  (RA)  is  the  starting  address  of  memory  assigned  to 
an  executing  program.  The  Field  Length  (FL)  is  the  length  of  that 
area.  These  hardware  registers  are  part  of  the  CPU,  but  are  not 
accessible  to  the  executing  program.  Their  use  is  completely 
transparent.  To  the  user,  all  memory  addresses  are  relative  to 
assigned  memory  and  the  hardware  precludes  any  other  access.  Thus  the 
CPU  program  does  not  handle  real  memory  addresses,  which  is  one 
characteristic  in  common  with  virtual  memory  systems.  This  eliminates 
user  part icipation  -  or  observance  -  of  memory  management.  Since  only 
the  Reference  Address  changes  when  a  program  is  moved  or  reloaded  into 
memory,  usage  can  be  highly  dynamic  and  efficient.  Doing  it  entirely 
in  hardware  provides  even  greater  efficency,  due  to  the  simplicity  of 
the  mechanism.  Here  we  see  both  security  and  performance  as  a  result 
of  how  memory  protection  is  implemented. 


[SLIDE:  User/System  Interface] 

Another  critical  secur i ty/perf ormance  concern  is  the  need  for  safe  and 
fast  context  switching  between  programs.  The  actual  context  switching 
mechanism  is  provided  by  a  hardware  feature,  which  has  been 
characterized  as  the  "ultimate  interrupt"  but  officially  known  as  the 
Exchange  Jump  operation. 

An  Exchange  Jump  can  be  triggered  by  either  a  PPU  or  a  CPU 
instruction.  This  single  instruction  stores  the  complete  set  of  CPU 
registers,  including  RA  and  FL ,  into  memory  and  reloads  them  from  the 
same  memory  block.  Yes,  it  sounds  like  magic,  but  it  does  go  both 
ways  in  the  sjame  operation.  The  result  is  a  complete  two-way  swap  of 
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-  the  execution  state  of  the  current  CPU  program  -  with  the  memory 
image  of  the  state  of  another  program.  The  whole  thing  is  transparent 
to  the  program  and  the  hardware  insures  that  nothing  is  lost  -  or 
cjajned  -  in  the  exchange. 

The  exchange  operation  is  very  fast.  For  comparison,  it  is  roughly 
the  same  time  as  a  floating  point  divide  operation.  In  some  processor 
models  it  is  even  faster.  In  that  case,  it  could  be  said  that  "a  swap 
is  faster  than  a  FLOP . "  Again  the  intent  was  performance,  but  the 
result  is  security  since  it  is  implemented  in  the  hardware. 

A  CPU  triggered  exchange  is  part  of  the  normal  user/system  inte' lace. 
In  this  case  the  user  program  merely  relinquishes  the  CPU  to  the 
operating  system.  On  completion  of  the  request,  the  CPU  is  returned 
in  a  similar  manner. 

The  system  PPU  monitor  however,  can  independently  trigger  a  context 
switch  at  any  time.  This  is  how  a  PPU  module  can  both  monitor  and 
control  the  time-slicing  of  the  CPU  among  many  jobs.  Tt  is  also  the 
mechanism  for  "pulling  the  plug"  on  programs  consuming  too  much  of  a 
resource  or  hung  up,  and  becoming  a  "denial  of  service"  threat  to 
others.  It  effectively  eliminates  of  any  form  of  user  lockup,  as  the 
PPUs  always  have  the  ultimate  control.  Thus  a  hardware  context 
switching  capability  can  provide  not  only  performance  and  security  but 
resource  control  as  well. 


[SLIDE;  Reliability  Features] 

Finally,  we  come  to  those  reliability  features  usually  thought  to  be 
interesting  only  to  engineers.  Error  detection  and  correction 
features  are  the  most  basic  elements  of  hardware  integrity.  An 
adequate  set  insures  that  the  hardware  will  yield  just  two  results  - 
either  a  correct  result,  or  a  signal  that  it  cannot  perform  the 
function  properly.  In  addition,  the  diagnostic  data  produced  by  these 
and  other  maintenance  controls  contribute  to  long  term  stability, 
reliability  and  recoverability.  My  point  is  that  they  are  not  to  be 
overlooked  when  considering  security.  We  are  all  aware  that  most 
system  flaws  are  exposed  when  operating  in  crisis  mode  -  usually  in 
response  to  an  error. 


[SLIDE:  Hardware  Secu r i ty /Pe r f o rma nee  (Result)] 

In  short,  there  are  four  key  hardware  characteristics  which  contribute 
heavily  to  both  performance  and  security: 

o  Machine  Architecture 

o  Memory  Protection 

o  Context  Switching 

o  Reliability  Features 
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All  ol  these  establish  the  base  on  which  software  must  rely,  to 
provide  both  security  and  performance  in  the  b^oad  sense. 


[SLIDE.  N  ..work  Operating  System] 

At  this  point  I  should  introduce  you  to  our  Network  Operating  System, 
(N.O.S.  or  NOS  as  you  will).  The  name  makes  it  clear  that  NOS  is 
network  oriented.  It  not  only  supports  access  via  communications 
networks,  but  also  supports  multi  computer  networks  both  locally  and 
remotely.  NOS  is  a  multi  mode  system  offering  a  full  range  of 
processing  modes  including  local  and  remote  batch,  database  managers 
and  transaction  processing,  and  a  variety  of  interactive  programming 
environments.  Obviously  it  is  a  multi  user  system  as  well,  and  that's 
where  security  becomes  a  key  requirement. 


[SLIDE:  NOS  Ch a ract e r i s t i cs ] 

One  of  the  outstanding  characteristics  of  NOS  is  that  it  is  a 
capabil ities  based  system.  It  all  begins  with  the  built-in  concept  of 
individual  users.  Each  user  must  be  known  to  the  system,  and  their 
capabilities  defined  on  an  individual  basis.  From  this  is  built  an 
accounting  system  where  every  activity  in  the  system  is  attributable 
and  traceable  to  a  user.  Users  are  totally  isolated  from  each  other, 
and  the  operating  system.  NOS  relies  heavily  on  the  hardware 
separation  and  memory  protection  features  for  this  isolation.  For  NOS 
users,  the  only  means  of  sharing  data  is  via  the  file  system.  The 
file  system  is  built  around  individual  ownership  of  files,  and  access 
is,  -  by  default  -  restricted  to  the  owner.  If  the  owner  chooses, 
other  users'  access  to  a  file  may  be  specified  on  the  basis  of  user 
identity  and  mode  of  access.  NOS  has  file  passwords  too,  but  they  are 
seldom  used  since  they  are  independent  of  ident i f icat ion . 

Interestingly,  the  file  system  carries  the  memory  addressing  concept 
much  further,  and  exhibits  most  of  the  characteristics  of  a  virtual 
memory  system.  Space  allocation  is  dynamic,  on  an  as-needed  basis, 
and  does  not  require  pre-allocation.  That  makes  it  very  space- 
efficient  and  avoids  deadlocks.  All  I/O  references  are  relative  to 
the  logical  file  name,  and  the  system  [a  PPJ  module)  does  the  mapping 
to  real  device  addresses.  Thus,  NOS  can  preclude  access  outside  of  a 
file,  and  to  unwritten  space. 

Users  and  their  files  are  also  qrouped  into  higher  level  FAMTLYs  with 
no  access  to  files  across  FAMILY  groups.  This  is  pa r t i cu 1  a r i ly 
valuable  in  a  university  environment,  to  separate  students  from 
faculty.  Families  are  then  divided  into  sub-families  by  storage 
device  to  provide  further  physical  separations.  The  result  is  that  a 
population  of  NOS  users  can  be  easily  managed  dynamically  and  without 
inconvi enence  to  the  user.  Both  Families  and  Sub-Families  may  be 
controlled  as  a  group  via  operator  commands. 

In  summary,  NOS  benefits  from  both  a  solid  hardware  security  base,  and 
a  design  intended  tor  commercial  timesharing,  which  has  withstood  the 
test  of  time  and  emerged  robustly  healthy. 
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[SLIDE:  Security  Requirements  (1  of  2)] 

But  what  of  the  DoD's  security  requirements?  Although  the  words  may 
differ,  there  is  a  strong  similiarity  between  commercial  and 
government  security  requirements.  When  you  speak  of  a  kernelized 
system,  it  must  be  as  simple  a  possible  -  to  allow  provability  -  and 
by  definition  must  be  modular.  It  would  be  interesting  to  compare 
this  concept  to  our  system  PPU  modules.  A  self-protecting  system 
doesn't  fall  apart  when  a  user  goofs.  Though  not  permissive,  it  must 
expect  and  tolerate  user  errors.  We  have  already  discussed  how 
integrity  relates  to  reliability.  User  privacy-by-default  is  a  more 
precise  description  of  isolation,  and  provides  protection  from 
accidental  access. 


[SLIDE:  Security  Requirements  (2  of  2)] 

Actually,  access  controls  are  a  subset  of  resource  controls.  Resource 
controls  also  deal  with  the  deni al-of-servi ce  threat.  Controlled 
sharing  is  where  security  is  the  name  of  the  game,  but  need-to-know 
access  controls  are  only  one  form  of  control.  Access  based  on  the 
identity  of  the  user,  and  control  based  on  ownership  is  another. 
Auditability  is  of  course,  more  narrowly  directed  toward  resource 
accountability.  But  it  also  provides  a  very  effective  user 
surveillance  capability. 

The  one  listed  government  security  requirement  without  a  commercial 
equivalent  is  the  concept  of  security  levels  and  categories. 

Actually,  they  are  just  different  sets  of  criteria  for  the  access 
controls  mentioned  above.  The  unique  aspect  is  that  levels  and 
categories  are  independent  of  data  ownership  and  subject  to  a 
mandatory  policy.  That's  the  hole  we  intend  to  fill. 

With  all  of  these  similarities,  it  should  not  be  surprising  then,  that 
a  system  meeting  one  set  of  requirements,  should  be  easily  adapted  to 
the  other.  In  fact,  while  adapting  the  NOS  design  to  support  levels 
and  categories  -  we  found  that  essentially  all  of  the  control 
mechanisms  were  already  in  place.  The  mechanisms  only  have  to  be 
extended  to  consider  levels  and  categories  and  the  mandatory  security 
policy  in  the  access  control  decision.  I t  is  clear  that  not  only  are 
the  requirements  similar,  but  are  convergent  on  a  common  set  of 
mechanisms.  Simply  put  -  form  follows  function.  Thus  we  believe 
there  is  a  common,  generic  set  of  control  mechanisms  which  can  be 
adapted  to  specific  security  policies.  There's  a  bonus  too  -  With 
those  generic  mechanisms  already  in  place,  we  are  confident  that  the 
Multilevel  Security  extensions  will  result  .n  no  significant 
performance  degrada t ion. 
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(SLIDE:  NOS  Multilevel  Security] 

With  the  NOS  Multilevel  Security  extensions,  we  will  have  the 
functional  capability  to  support  Multilevel  Mode  operations.  This 
will  be  a  standard,  fully  equipped  operating  system,  for  use  with  our 
large  scale,  high  performance  computers.  It  will  be  compatible  with 
the  full  line  of  CYBER  170  computers,  and  most  predecessor  machines. 

It  will  offer  the  full  set  of  standard  software  products,  and  will  be 
software  compatible  with  existing  NOS  user  applications.  i  )S  with  MLS 
will  also  be  available  not  only  to  new  customers,  but  to  installed 
customers  as  well,  which  goes  a  long  way  toward  the  goal  of 
"widespread  availability." 

That's  what  we  are  doing  as  pract i t ioners  of  computer  security.  But 
how  does  that  relate  to  the  DoD  Initiative  and  the  theoretical  work? 


[SLIDE:  Computer  Security  Approaches] 

As  you  can  see.  Control  Data  has  been  approaching  computer  security 
from  a  practitioner's  viewpoint.  Our  first  concern  has  to  be 
functional  requirements,  since  we  are  selling  not  just  hardware  and 
software  but  capabilities.  Design  evolution  recognizes  the  fact  that 
we  must  maintain  compatabi 1 i ty  with  previous  systems  and  the  user's 
applications.  Marketability  is,  in  fact,  not  the  least  concern,  but 
the  one  driving  all  other  concerns. 

From  a  theoretical  approach,  it  is  clear  that  computer  security  must 
begin  with  the  design  methodology,  with  the  objective  being 
provability.  The  idea  ofa  formal  evaluation  and  on-the-shelf 
certification  is  also  important,  and  a  pragmatic  concern  as  well.  But 
what  really  drives  a  manufacturer  is  marketability.  In  this  case,  it 
seems  our  concerns  are  markedly  different.  But  let's  look  at  the 
respective  methodologies  to  see  if  that  difference  holds  up  on 
examination. 


[SLIDE:  Development  Methodologies] 

Here  we  can  compare  the  formal  design  methodologies  with  those  used  by 
informal  practitioners  like  Control  Data.  Obviously,  both  processes 
begin  with  some  form  of  requirements.  Formally,  the  security  model 
serves  as  a  target  requirement.  But  as  usual,  a  manufacturer  is 
driven  by  market  requirements,  which  are  often  conflicting  and  subject 
to  internal  constraints  as  well.  Eventually,  requirements  are  agreed 
upon  and  functional  specifications  are  created.  These  are  roughly 
equivalent  to  Top  Level  Specifications  and  here  the  two  processes  are 
very  similar.  In  the  formal  process,  the  specs  are  then  verified  to 
the  security  model,  while  informally  a  Design  Review  occurs.  A  Design 
Review  can  be  just  as  tough  to  do  as  a  logical  verification,  and  a  lot 
more  emotional.  Where  a  detailed  design  is  done  formally,  coding 
specs  emerge  informally.  Now  formal  design  correspondence  may  be 
compute- intensive,  but  peer  review  of  all  generated  code  is  people¬ 
intensive.  We're  not  sure  which  is  more  expensive,  but  neither  is 
cheap!  We  have  been  told  that  complete  code  verification  is  beyond  the 
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state-ot-the-a rt ,  well  complete  system  testing  may  be  also  -  but  we 
keep  on  trying.  In  penetration  analysis  we  are  doing  essentially  the 
same  thing.  At  Control  Data,  we  call  it  Malicious  User  Group  or  MUG 
system  testing.  T  ts  fun,  and  occasionally  very  exciting!  Finally, 
there  is  an  evaluation  of  the  resulting  system  by  someone  whose 
opinion  is  important  to  the  developer.  For  commercial  systems,  it  is 
simply  market  acceptance  by  the  user.  It  would  be  nice  however,  to 
have  a  formal  stamp  of  approval  before  shipping  the  system. 

The  objectives  of  these  methodologies  differ  markedly  however.  For 
formal  methodologies,  it  is  Provability,  but  for  commercial  systems  it 
is  Fur.ctionali  ty.  In  most  other  respects  they  are  not  only  similar, 
but  appear  to  Conve  rge  on  a  common  set  of  developmental  functions. 

This  convergence  has  encouraged  Control  Data  to  look  into  applying 
some  of  these  formal  methods  to  our  system.  As  a  first  step  in  that 
direction,  we  have  requested  a  DoD  evaluation  of  ou1'  NOS  system  and 
Multilevel  Security  design.  That  process  is  underway,  and  so  far  it 
looks  very  promising.  On  the  matter  of  formal  design  verification,  we 
understand  the  benefits,  but  will  have  to  develop  the  means  of 
applying  the  theory  to  our  practices.  We  are  currently  exploring  some 
alternatives  in  that  area. 


[SLIDE:  DoD  Initiative  Impact] 


In  conclusion,  we  at  Control  Data  applaud  the  progress  of  the  DoD 
Computer  Security  Initiative.  We  would  especially  like  to 
congratulate  you  - 

o  On  increasing  industry  awareness  of  the  need  for  security.  (Some 
non-DoD  people  have  helped  too  -  by  getting  caught.) 

o  We  thank  you  for  fostering  -  and  occasionally  funding  -  the 
development  of  computer  security  technology. 

o  Thanks  too,  for  f ocus i ng  computer  security  requirements  for  those 
not  so  knowlegeable  in  computer  security.  This  directly  benefits 
manufacturers  by  limiting  the  ingenuity  of  those  who  write 
technical  specifications  for  procu rements . 

o  And  finally,  we  thank  you  for  providing  an  evaluation  framework 
which  places  greater  emphasis  on  Junctional  capabilities  than  on 
technical  sped  f  i  ca  t  ions  . 


We  look  forward  to  a  fruitful  dialog  on  our  common  objectives  of 
advancing  the  state-of-the-a rt ,  and  acheiving  the  widespread 
availability  of  Trusted  Computing  Bases. 

Thank  you  for  the  opportunity  to  address  this  forum. 


[SLIDE:  CDC  Logo  or  DoD  slide] 
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•  STANDARD  SYSTEM 

-  LARGE  SCALE  SYSTEMS 

-  PERFORMANCE 

•  COMPATIBILITY 

-  HARDWARE 

-  SOFTWARE 

•  AVAILABILITY 

-  NEW  CUSTOMERS 

-  INSTALLED  CUSTOMERS 


| 

COMPUTER  SECURITY  APPROACHES  | 

THEORETICAL 
DESIGN  METHODOLOGY 
DESIGN  VERIFICATION 
FORMAL  EVALUATION 


PRACTICAL 

functional  requirements 

DESIGN  EVOLUTION 
MARKE  T ABILITY 


DEVELOPMENT 

METHODS 

THEORY 

PRACTICE 

SECURITY  MODEL 

MARKET  REQUIREMENTS 

TOP  LEVEL  SPECIFICATIONS 

FUNCTIONAL  SPECIFICATIONS 

DESIGN  VERIFICATION 

DESIGN  REVIEW 

DESIGN  CORRESPONDENCE 

PEER  REVIEW  OF  CODE 

CODE  VERIFICATION 

UNIT/SYSTEM  TESTING 

PENETRATION  ANALYSIS 

IN  HOUSE  USE/TESTING 

FORMAL  EVALUATION 

USER  ACCEPTANCE 

,1  ■  -  II  •  ■  ■  I.  ,  I  .1  1 1. 1  , 

DOD  INITIATIVE  IMPACT 

•  AWARENESS 

•  TECHNOLOGY  STIMULUS 

•  FOCUS  FOR  REQUIREMENTS 

•  EVALUATION  FRAMEWORK 
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SAC  Digital  Network 
(SACDIN) 

Security  Methodology 


Slide  1 

Slide  2 

Slide  3 

Slide  4 

Slide  5 
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Mauro  Ferdman 
The  MITRE  Corporation 


PRESENTATION  OUTLINE 


SACDIN  will  be  used  to  support  command  and  control  functions  of  the 
Strategic  Air  Command. 

Present  status  of  the  project  is  full-scale  engineering  development. 
Prime  contractor  is  ITT  and  the  major  subcontractors  are  IBM  for 
software  and  BDM  for  systems. 

SACDIN  is  a  large  scale  network  covering  all  SAC  units  throughout 
the  continental  U.S.  It  is  a  packet-switched  network  and  it  uses 
AUTODIN  II  as  a  backbone.  One  of  the  characteristics  of  SACDIN 
that  is  important  for  this  seminar  is  that  it  is  designed  to  be 
mutli-level  secure. 

The  security  requirements  are  very  strict  and  as  it  was  mentioned 
before,  they  include  requirements  for  simultaneous  transmission  of 
messages  of  different  classification.  It  provides  protection 
against  compromise  of  information,  integrity  and  denial-of-servi ce . 

The  IACM  provides  total  mediation  between  subjects,  which  are  the 
users  of  information,  and  the  objects  which  are  the  repositories 
of  information.  The  IACM  mediates  every  single  access  of  subjects 
to  objects. 

The  IACM  mediates  all  accesses  so  it  must  be  some  assurances  that 
it  was  designed  and  implemented  correctly.  This  has  required 
that  a  specialized  software  design  methodology  be  used  and  it  will 
be  described  later.  In  addition,  there  must  be  some  ways  of 
protecting  the  IACM  from  being  altered  by  other  software. 

SACDIN  has  three  tiers  of  protection  provided  by  the  applications 
processes  which  are  used  for  user  support,  the  trusted  processes, 
which  are  used  for  I/O  Interfaces  and  the  IACM  or  Internal  Access 
Control  Mechanism,  which  also  serves  as  the  Opeiating  System.  The 
next  slides  will  explain  in  more  detail  the  security  enforcement 
mechanism  of  the  IACM. 

The  methodology  used  for  development  of  the  IACM  consisted  of 
creating  a  mathematical  model  to  formally  represent  DOD  security 
policies,  followed  by  a  formal  description  of  the  IACM  design  in 
a  formal  language  which  was  formally  verified  not  to  violate  the 
math  model.  Lower  level  specifications  were  only  correlated  in  a 
less  formal  way. 
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Slide 

Slide 

Slide 

Slide 

Slide 

Slide 

Slide 

Slide 

Slide 
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Slide 


9  :  In  a  more  graphical  way,  the  bottom  line  shows  the  standard  1)01) 

Procurement  practices  for  software,  from  user  requirements  to  code, 
with  the  proper  test  and  evaluations.  Our  methodology  lias  added 
the  upper  part  in  parallel  to  provide  a  better  assurance  of  a 
correct  design. 

10:  We  quickly  found  that  the  IACM  by  itself  was  not  enough  to  protect 

against  compromise.  There  were  problems  in  these  cases  where 
information  must  be  transferred  into  or  out  of  the  Central  Processor, 
such  as  network  communications,  peripheral  devices,  etc.  The 
following  slides  will  deal  with  these  problems. 

11:  A  host  or  node  contains  an  IACM  and  it  is  fully  capable  of  handling 

multi-level  communications  such  as  from  A  to  B  or  access  to  the 
Multi-Level  Data  Base,  marked  as  Ml.DB  in  the  slide. 

12:  If  we  have  a  network,  and  now  A  attempts  to  communicate  with  C  or 

B  with  D,  we  are  dealing  with  multiple  lACM's,  one  in  each  node, 
so  it  is  important  that  the  last  software  process  that  handled  the 
message  be  trusted. 

13:  The  situation  is  more  complicated  through  the  use  of  a  back-bone. 

See  in  the  slide  the  path  from  A  to  C  and  K  to  D. 

14:  The  solution  that  we  adopted  was  to  create  specialized  software 

that  serves  to  authenticate  one  node  to  another  and  to  serve  as 
I/O  transmission  control.  It  earned  the  name  trusted  because  it 
used  the  same  design  methodology  as  the  IACM. 

15:  The  problem  with  peripheral  devices  are  similar,  because  the  IACM 

does  not  have  direct  control  of  the  information  going  outside 
the  Central  Processor.  The  solutions  adopted  were  similar  to  t  lie 
ones  adopted  for  communications,  namely  to  use  trusted  software 
to  handle  the  printer  and  user  interface. 

16:  As  far  as  integrity  protection  is  concerned,  it  was  based  on  using 

good  software  practices  as  shown  in  the  slide. 

17:  The  Central  Processor  that  we  used  is  a  modified  ot t - t he- she  1 t 

computer,  the  IBM  Series/1,  with  several  security  features  added. 

They  consisted  of  an  expanded  relocation  translator,  a  security 
controller  to  monitor  accesses  to  core  and  an  expanded  instruction 
set.  The  terminal  was  specially  developed  and  it  includes  a  special 
security  field. 

18:  Summary  and  concl usions . 

19:  Lesson  learned. 


Internal  Access  Control 
Mechanism  (IACM) 


Mediates  All  Access 
Formally  Proven  Secure 
Protected  From  Modification 
Serves  As  OS 


Software  Architecture 


APPLICATION 

PROCESSES 


TRUSTED 

PROCESSES 


PERIPHERAL  DEVICES 
AND  INTERFACES 


IACM  Development  Methodology 

Formally  Represent  Security  Policies  (Math 
Model) 

Prepare  Formal  Top  Level  Specifications  (B-5) 
Formally  prove  specifications 
Intermediate  Language  Representation 
Correlations  proofs 
Stepwise  Refinements 
Correlation  proofs 
Implementation  Code 
Correlations  proofs 
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IACM  Development  Methodology 


1  DOD 

MATH 

|  POLICV 

FORMAL 

MODEL 

VERIFICATION 


FORMAL 

VERIFICATION 


1  REOMTS  \ 


1 

FORMAL 

SPECS 
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CORRE 

LATIQNS 


FORMAL 
DESIGN 
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corre¬ 

lations 


CORRELATIONS 
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USER 

REOMTS 

* 

A 

SPECS 

- 

B 

SPECS 

- 

C 

SPECS 

* 

PRODUCT 
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OT&E  :  OTAE 


IACM  Not  Enough  To  Protect 
Against  Compromise 


Network  Problems 
Peripheral  Devices  Problems 
Multi-Level  Files 


Multi-Level  Problems  In 
Networks  Host  Problem 


TS 

S 

~c~ 

u 


o  o 

A(S)  B(TS) 
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Summary 


HAl  DIN  Is  I  irst  Mulli-Lrvrl  Network 
With  Strut  SeturiU  Requirements  From 
Proqrom  Inception 

l  ses  Spet  ialired  Software  Development 
Methodology  Reaching  As  Far  As  the 
Prat  tit  al  State-of-the-Art  Will  Go 

thorough  Security  Analysis  Throughout 
Design  and  Development 

Collaborative  Effort 


Lessons  Learned 


l  arge  Amount  of  Trusted  Software 
Required  Over  and  Above  Basic  Kernel 

Largest  Security  Problem  Is  the  Handling 
of  Peripherals  and  Communications 
Lines.  Not  the  Internal  Handling  of  Data 
Multi-Level  Security  Can  Be  Achieved  If 
Svstem  Is  Carefully  Planned.  Designed 
and  Developed 
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COS/NFE 

OVERVIEW 


Gary  Grossman 

Digital  Technology  Incorporated 

August  10.  1981 


Preview 

•  COS/NFE  Program 

•  COS/NFE  Technical  Description 

•  HUB™  Executive 

•  Security  Methodology 

•  Experience 

D  T  I 

I  ■  I—  —  * 
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Communicatin'! 

Operating 

S  ystem 

/ 

N  etwork 
F  ront 
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COS/NFE 

•  Verifiably  secure 

•  Prototype  NFE 
.  For  AUTODIN  II 


Lineage 

DTI  Secure 
HUB™  Executive 

COS/NFE 


Precursors 


ENFE 

Network  UNIX  +  UPC 

ARPANET 

U  of 

INFE 

UNIX  +  Attach  1  0 

AUTODIN  II 

DTI 

WNFE 

UNIX  +  Attach  1  0 

WIN 

DTI 

DTI 


Participants 


DCA 

-  Sponsor 

DTI 

-  Prime 

design  &  implementation 

SDC 

-  Sub 

formal  specs.,  verification, 
A  security  analysis 

ISET 

-  Security  Watchdog 

* 


Goals 

•  Security 

Overt  channels 
Covert  channels 
Denial  of  service 

•  Performance 

'Significantly*  better  than  INFE 


OTl 


•  Hardware 


pnp-i  1/ro 


Software 


Secure  HUB" 
PASCAL 


Execut 


Schedule 

•  Completion  -  March  '83 

•  Trusted  security  control  -  soon 


COS/NFE  Functions 

•  Identical  to  INFE  +  security 

•  Interfaces 

•  Protocols 


COS/NFE  Interfaces 

•  AUTODIN  II 

ACC  UMC-2S0 

.  WWMCCS  H6000 

ACC  LH  OH- 11  -  ABSI 

•  Terminals 

DH- 1  1  Asynch 
DV-1  1  Synch  VIP 


COS/NFE  Protocols 

•  AUTODIN  II 

THP.  TCP.  IP.  SIP,  Mode  VI 

.  WWMCCS  H6000 

HFP  :  SAP's,  Channel.  Link 

•  Terminals 

Asynch  Character  Start-stop 

Synch  Honeywell  VIP 


COS/NFE  Modules 

•  Protocol  processing 

From  INFE 

•  Admin.  &  security 

Cl  -  designed,  coded 
TH  -  designed,  coded 
Others  -  designed,  being  coded 

•  HUB™  Executive 

Oeslgned.  coded,  tested  to  usefulness 
for  measurements 
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Relative 

Speed  of  IPC  Operations 

• 

Includes  all  related  primitive  calls 

Buffer  allocation 

Sending  message 

Receiving  message 

• 

Attach  I/O  6.95ms 

• 

HUB™  3.9ms 

• 

Ratio  1.75 

• 

Functions  may  not  be  comparable 

UTi 

HUB™ 

Primitives 

• 

Resource  management 

10 

• 

Process  management 

3 

• 

Address  space  management 

2 

• 

IPC 

7 

• 

Flow  control 

5 

• 

I/O 

4 

• 

Timing 

1 

32  n  r  • 

TU 

HUB  Concepts 

•  Stages  (processes) 

•  IPC 

•  Sessions  (domains) 

t'»i 

I-H 
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HUB™  Security 

•  Overt  channels 

•  Covert  channels 

•  Denial  of  service 

O’. 

1 - 

1  Overt  Channels 

• 

Formal  control 

• 

Definition  of  "trused” 

• 

Communication  rule 

• 

Execution  rule 

nn 

j 

t - 

I  Covert  Channels 

9 

Engineering 

9 

Few  shared  resources 

9 

Strict  controls  on  resources 

• 

Only  trusted  software  can  move 
resources 

OTI 
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Correctness  Criterion 

•  One  for  each  trusted  module 

•  Relatively  simple 

•  Security-related  only 


DTI 


Top-Level  Specification 

•  Correctness  criterion 

•  Initial  conditions 

•  Variables 

•  Transforms 


Second-Level  Specification 

•  Mapping  to  TLS 

•  Refinement 

Variables 

Transforms 


Comparison  of  2LS  S  Code 
•  EG:  HUB™ 


2LS:  2400  lines  of  INA  JO 
Code:  2838  lines  of  PASCAL 


r — 

' 

I  Performance  Experiment 

• 

TCP:  HUB™  vs.  INFE  UNIX™ 

• 

Security  with  HUB™ 

Resource  allocation:  46%  of  CPU 

• 

More  IPC  with  HUB™ 

• 

HUB™:  PASCAL,  UNIX:  C 

• 

HUB™  17%  faster 

DTI 

,  -  «  —  » 

Security  Experience 

•  SDC  analysis 

•  ISET  evaluation 

.  Proof  of  HUB™  2LS,  2000  pages 


Things  to  Come 

Verification  continuing 
INFE  protocols  to  HUB™ 
HUB™  to  other  processors 
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HUB™ Executive  Transform  Communicate 

From  HUB  Executive  MA-JO™  TOP  LEVEL  Specification 

TRANSFORM  COMMUNICATE(B:BUFFER,SI.SJ:SESSION) 
EXTERNAL  EFFECT 

SLS  OF  BUFFER(B)  « 

SLS  OF  SESSION(SI)  AA  SLS  OF  SESSION(SJ) 

&  B  <  BUFFERS  OF(SI) 

A  ACTIVE  SESSION(SJ) 

A  SI  "  SJ 
A  A  SESS  SESSION! 

N  BUFFERS  OF(SESS) 

(SESS  SI  >  BUFFERS  OF(SESS)  *•**  S  (B) 

<>  SESS  SJ  >  BUFFERS  OF(SESS)  S"(B) 

<>  BUFFERS  OF(SESS))) 

NC  (BUFFERS  OF) 
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WIS  Security 
Strategy 


Larry  Bernosky 

Defense  Communications  Agency 
WWMCCS  System  Engineering 


WWMCCS  Information 
System:  Target  Architecture 

Goal.  Reliable  Connectivity  Among  All  Sites 
World  Wioe  Net 


Package  Package  Unique 

A  B  SuppoM 


DOD 

Security  Regulations 


•  DOD  Directive  5200.28 

•  JCS  Publication  22 

•  Army  Regulation  380-380 

•  DIA  Manual  50-4 

•  .  . . 

•  .  .  . 

•  .  .  . 


Current  Security 
Control  Techniques 


•  System  High 

•  Dedicated  Systems 

•  Periods  •  Processing 


Characteristics  of 
Current  Controls 


•  Static 

•  Long  Lead  Time  to  Implement 

•  Expensive 

•  Limited  Extensibili.y 


WWMCCS 
Environment  Trends 

•  Increasingly  Complex  Processing  Needs 

•  Extensive  Internetting  and  Intranetting 

•  Evolution  Toward  Distributed  Control 

•  Temporary  Reliance  on  Monolithic  Machines 
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WIS  Security  Goals 


Objective:  Provide  “Adequate"  Security  for  WIS 

•  Satisfy  the  Security  Policy 

•  Allow  WIS  to  Perform  Its  Required  Functions 

•  Make  Controls  Transparent  to  the  User 

•  Allow  for  Evolutionary  Upgrades 


ARCHITECTURE  PHASES 
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WIS  Security  Architecture 

TSIS  TSIS 


User 

Support 


Security 

Monitor 


TS/S 

Local  Network 


Multilevel 


WIS  Operational 
Scenarios 


Support  for  Homogeneous  User  Access 


•  User  (S)  Requests  Access  to  Data  on  a  Secret  Processor 

•  CUS  (S)  Validates  User  Identity  and  Access  Request 

•  CUS  (S)  Forwards  Request  to  Processor  (S)  via  Trusted  Multilevel  Local  Net 

•  Processor  (S)  Validates  Request  and  Forwards  Data  to  CUS  (S) 

•  CUS  (S)  Queues  Data  tor  User  (S) 


Support  for  Low  to  High 
User  Access 

Description 

•  Confidential  (or  Secret)  Remote  User  Requires  Access  to 
Selected  Data  from  a  TS  System  High  Processor 

•  Access  Control  Mechanism  is  Needed  to  Screen  Request  and 
Validate  User  Identity 

•  Information  from  TS  Processor  Must  be  ReviewedfSanitized 
Before  Delivery  to  Low  User 

Requirements 

•  Local  Support  is  Needed  for  Users  at  Different  Classification 
Levels 

•  Local  Network  Needs  to  Support  Remote  Terminals 

•  Data  Base  Needs  to  Contain  Material  at  Different  Classification 
Levels 

•  Data  Base  Needs  to  be  Accessed  by  Authorized  Users  Having 
Differing  Security  Clearances 

-  -  . ^ 


Support  for  High  to  Low 
User  Access 


•  User  (TS)  initially  Connected  to  Top  Secret  CUS 

•  User  (TS)  Disconnects  (Physical  Switch  or  Trusted  SW)  from  CUS  (TS)  After 
Storing  Working  Files  in  CUS  (TS) 

•  User's  Terminal  is  Sanitized  Automatically 

•  User  (TS)  Connects  to  Secret  CUS 

•  Access  to  Secret  Processor  is  Made  via  CUS  (S) 

•  User  (TS)  May  Switch  Back  to  Top  Secret  CUS  Without  Sanitizing  Terminal 


A 


Support  for  High  to  Low 
User  Access 

Description 

•  Top  Secret  User  Requires  Access  to  Data  on  a  Secret  Processor 

•  Secret  Data  is  Released  to  Top  Secret  User 

Requirements 

•  CUS  Needs  to  Provide  Multilevel  Support  for  a  TS  User 

•  Mechanism  is  Needed  to  Prevent  Release  of  TS  Data  into 
an  S  Environment 

•  User  Performance  Must  Not  be  Adversely  Affected  by  Security 
Controls 


Support  for  Low  to  High  User  Access 


•  User  (S)  Requests  File  Controlled  by  TS  System  High  Processor 

•  CUS  (S)  Validates  User  Identity  and  Access  Request 

•  CUS  (S)  Forwards  Request  to  Processor  (TS) 

•  Processor  (TS)  Validates  Request  and  Forwards  File  to  Security  Monitor 

•  Security  Monitor  Forwards  Reviewed  File  to  CUS  (S) 

•  CUS  (S)  Queues  File  for  User  (S) 


Message  Receipt  and  Distribution 


Description 

•  AMH  Receives  Secret  Labeled  Message  Over  TS  Communication 
Line  for  Distribution  to  Selected  Local  TS  and  S  Users 

•  Message  Must  Be  Reviewed/Sanitized  Since  TS  Data  May  Have- 
Been  Mixed  with  Message  on  Long  Haul  Net 

•  Message  is  Queued  to  Common  User  Support  (CUS)  for  TS 
and  S  Users 

Requirements 

•  Local  Network  Needs  to  Maintain  Separation  of  Classified 
Material  While  on  the  Net  and  When  Entering  or  Leaving  the  Net 

•  CUS  Needs  to  Support  Terminals  Operating  at  Different 
Security  Levels 

•  Message  Handling  and  Distribution  Functions  Need  to  Support 
Different  Security  Levels 

•  Selected  Classified  Information  Needs  to  be  Reviewed 
or  Sanitized 
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Message  Receipt 
and  Distribution 


Essential  1 

•  AMH  (TS)  Receives  Message  (S) 

•  Message  Queued  for  TS  Users  at  CUS  (TS) 

•  AMH  Forwards  Message  to  Security  Monitor  With  Addresses  of  S  Users 

•  Security  Monitor  Queues  Reviewed  Message  at  CUS  (S) 


Message  Receipt 
and  Distribution 


Essential  2 

•  AMH  (TS)  Receives  Message  (S) 

•  Message  Queued  for  TS  Users  at  CUS  (TS) 

•  AMH  Forwards  Message  to  Security  Monitor 

•  Security  Monitor  Sends  Reviewed  Message  to  AMH  (S) 

•  AMH  (S)  Queues  Message  for  S  Users  at  CUS  (S) 


Message  Receipt 
and  Distribution 


Desirable 

•  If  Message  Could  Contain  TS  Data,  the  AMH  Routes  Message  to  Security 
Monitor 

•  Security  Monitor  Sends  Sanitized  Message  Back  to  AMH 

•  AMH  Queues  Message  (S)  to  Both  TS  and  S  Users  via  Appropriate  CUS 


WIS  Multilevel 
Long-Haul  Connections 


Description 

•  Two  WIS  Sites  Operate  at  Different  Maximum  Security  Levels 

•  Sites  Need  to  Exchange  Information 

•  TS  to  S  Message  Flow  Must  be  Reviewed/Sanitized 

Requirements 

•  Long-Haul  Network  Needs  to  Support  Local  Users  Operating  at 
Different  Security  Levels 

•  Long-Haul  Network  Needs  to  Connect  WIS  Nodes  Having 
Different  Ranges  of  Classified  Information 

•  Material  with  Different  Classification  Levels  Needs  to  be 
Transmitted  Over  the  Long-Haul  Network 
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WIS  Multilevel 
Long-Haul  Connections 


Site  A  (TSiS)  Sit*  B  (S) 


Essential  1 

•  Site  B  <S)  Requests  File  from  Site  A  (TS/S)  via  NFE  (TS) 

•  It  File  at  A  is  on  TS  Processor  then  File  is  Passed  Through  Security  Monitor  at 
A  to  Verity  File  Contents  Are  at  S  Level 

•  Security  Monitor  Forwards  File  (S)  to  NFE  (TS) 

•  NFE  (TS)  at  B  Receives  File  Which  is  Sent  to  Security  Monitor  at  B  to  Verity 
That  No  Moditications  Occurred  on  the  Long  Haul  Net  (Perhaps  by  a  More 
Rigorous  CRC  Type  Authentication) 

•  Security  Monitor  Forwards  File  (S)  to  Appropriate  Locations  on  Local  Net  B 


WIS  Multilevel 
Long-Haul  Connections 


Site  A  (TS/S)  Site  B  IS) 


Essential  2 

•  Site  B  (S)  Requests  File  from  Site  A  (TS/S)  via  NFE  (TS) 

•  Site  A  Forwards  File  to  Site  B  via  NFE  (TS) 

•  NFE  (TS)  at  B  Forwards  File  to  the  Security  Monitor  at  B  for 
Review/Sanitization  to  S  Level 

•  Security  Monitor  Forwards  File  (Si  to  Appropriate  Locations  on  Local  Net  B 
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WIS  Multilevel 
Long-Haul  Connections 


Sit*  A  US'S)  Sit*  B  fS) 


Desirable 

•  Site  B  (S)  Requests  File  from  Site  A  (ISIS)  via  MLS  Long  Haul  Network  and 
MLS  NFE 

•  If  File  at  A  is  on  TS  Processor  Then  File  is  Reviewed/Sanitized  by  Security 
Monitor  at  A 

•  Security  Monitor  Forwards  File  (S)  to  S  Portion  of  NFE  (TS/S) 

•  Long  Haul  Net  (TS/S)  Guarantees  File  Received  at  B  is  S  Level 

•  NFE  (S)  at  Site  B  Forwards  File  (S)  to  Appropriate  Location  on  Local  Net  B 


* 


Interconnection  Trusted  Software  Encryption  Policy 
—  Protocols  —  Veriticalion  —  EJ  —  5200.28 


—  Assessment 

—  Experiments 

—  Action  Items 


* 
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Security  Flexibilities 
in  the  Local  Network 


•  Reduced  Need  to  Share  Hardware 

•  Can  Support  Several  Different  (Tailored)  Security 
Approaches 

e  Use  of  Specialized  Solution  Approaches 

•  Evolutionary  Implementation  and  Upgrade  Possibilities 


SAFE  Description 
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SAFE  •  WIS  Summary 


•  Similar  High  Level  Design;  Many  Specifics  Differ 

•  Need  to  Analyze  Traffic  Characteristics  Impact 

•  E3  Protocol  Analysis  and  BIU  Development  Will  Benefit 
WIS 

•  SAFE-Type  Crypto  Modules  Can  be  “Easily”  Incorporated 
in  Reston  Testbed 

•  NSA  Will  Develop  Crypto  Devices  if  WIS  Requirements  Are 
Clearly  Specified  in  Time 

•  Need  to  Continue  Tracking  SAFE  Effort 


Trusted  Interface  Unit 


Broadband  Cable 


Memory 


Security 

Processor 


IIO  Port 


Terminal/Host 


Progress 


•  Security  Requirements  Have  Been  Refined 

—  Scenarios  Addressing  Known  Security  Problem 
—  Inputs  to  WIS  Requirements  Survey 

•  Local  Net  Security  Task  Force 

—  Evaluate  Issues  of  Encryption,  Trusted  Software, 
Security  Protocols 

—  Examine  Technologies  Within  WIS  Context 

•  Security  Architecture  for  WIS  Has  Been  Developed 

—  Operating  Mode  for  Transition  Components  Defined 
—  Mandatory  and  Optional  Requirements  Identified 
—  Technology  to  Support  Security  Requirements  for 
Components  Identified 


WIS  Security 
Summary 

•  More  EFFICIENT  SECURITY  Controls  Are  VITAL  to  WIS 

•  NOT  Seeking  ABSOLUTE  Multilevel  Security 

•  LOCAL  NET  Architecture  Affords  More  FLEXIBILITY  in 
Solving  Problem 


TRUSTED  COMPUTING  RESEARCH 
AT 

DATA  GENERAL  CORPORATION 


Leslie  DeLashmutt 
Doug  Wells 

Research  Triangle  Park 
North  Carolina 


Goal 

Controlled  sharing  of  information  in  a 
distributed,  multi-user  environment 
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Overview 


Access  control  approaches 

•  Capabilities 

•  Access  control  lists  (ACLs) 
Confinement  approach 

•  Domains 
Extended  types 


Subjects 


Protection  Model 


Object 


Subject 


Active  subjects 
Passive  objects 
Access  rights 


Protection  Checking 
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Design  Considerations 

•  Number  of  subjects  and  objects  may  be 
large 

•  No  protection  attributes  for  some 
subject/object  pairs 

•  Matrix  may  be  sparse 

•  Identical  protection  attributes  for  subjects 
or  objects 

•  Only  small  part  of  matrix  necessary  at  any 
one  time 


Capability  Systems 
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Subjects 


r  1 

Evaluation  of  Capabilities 

Virtues 

Problems 

•  Protection 

•  Forgery  of  keys 

•  Simplicity 

•  Accountability 

•  Flexibility 

•  Revoking  access 

•  Efficiency 

•  Controlling  propagation 

•  Access  review 

Access  Control  List  Systems 
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PROTECTION  USING  ACCESS  CONTROL  LISTS 


Positive  Features  of  ACL  Systems 


•  Granting  access  has  known,  auditable 
consequences 

•  ACLs  directly  implement  verification  of  an 
access  request 

•  Access  revocation  is  manageable 

•  Each  ACL  lists  authorized  users  of  an 
object 

•  Break  association  between  data 
organization  and  authorization 

•  Natural  to  the  user 

•  Minimal  hardware  implementation  costs 

•  Readily  adapted  to  heterogeneous  networks 

•  Natural  primitive  for  a  high-level  security 
language 

•  Provide  top-down  view  of  security 


CAPABILITY  ACQUISITION 
IN  A  HYBRID  SYSTEM 
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Limitations 

♦  Only  system-defined  access  restrictions 
enforced 

•  No  protection  of  user  from  borrowed 
program  "trojan  horse” 

*  No  protection  of  borrowed  program  from 
user 


Beginning  Domain  Model 


Subject! 


Simplified  Cross- Domain  Call  Example 


Process  1 4 


Procedure  0 
DOE  =  User 


Procedure  1 

DOE  =  Opsys 


Subject 


[Jones, User] 
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[Jones,  Opsysl 


Procedure  2 

DOE  =  User 


[Jones,  User] 


Potential  Implementation  of  Domains 

•  Interprocedure  call  and  return 

•  Problem:  no  architectural  assurance  that  a 
procedure  can  access  its  arguments  when 
called  in  a  new  domain 


•  One  solution:  dynamic  access  capabilities 
on  cross-domain  calls 


Extended-Type  Object  Example 


ETM  for 

Extended-Type  Objects 
of  Type'Stack'’ 


UID  38848 


Header 

Pr  cedure  i 
Create  stack 

Procedure  2 
De'ete  stack 

Procedure  3 
Push 

Procedure  4 
Pop 

Extended-Type  Objects 
of  Type  "Stack" 
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Frame  2 


STEP 


Extended-Type  Manager  Example 


SuCxect* 
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Future  Directions 


•  Military  security  model 

•  Flow  control 

•  '-property  (prevention  of  write-down) 

•  Formal  specification  of  design 

•  Formal  model  for  security  in  our 
architecture 

•  Fault  tolerance 

•  Encryption 

•  Sophisticated  authentication  mechanisms 


Summary  of  DG/RTP  Activities  to  Date: 

•  Made  critical  survey  of  primitives  available 
to  support  a  trusted  computing  base 

•  Selected  the  best  concepts  to  support  such 
a  base 

•  Integrated  these  concepts  into  a  coherent 
architecture 
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Architecture” 
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THE  iAPX-432 

MICROCOMPUTER  SYSTEM 

1  !  •[ 

i  i.  *. 

•  VLSI  COMPONENTRY 

•  ARCHITECTURE 

•  OPERATING  SYSTEM 

•  SYSTEM  LANGUAGE 


432  MOTIVATIONS 

•  HIGH  PERFORMANCE  MOS/VLSI  (HMOS) 

•  RECENT  COMPUTER  SCIENCE  RESEARCH 

•  ADVANCING  MICROCOMPUTER  APPLICATIONS 


432  DESIGN  OBJECTIVES 

•  LARGE  SCALE  COMPUTING  POWER 

•  INCREMENTAL  PERFORMANCE  CAPACITY 

•  INCREASED  PROGRAMMER  PRODUCTIVITY 

•  DEPENDABLE  HARDWARE  AND  SOFTWARE 


KEY  CONCEPT:  DATA  ABSTRACTION 


•  MODULAR  DATA  STRUCTURES  AND  PROCEDURES 

•  WELL-DEFINED  MODULE  INTERFACES 


•  OBJECT-ORIENTED  PROGRAMMING  METHODOLOGY 


KEY  CONCEPT:  HIGH  LEVEL  FUNCTION 


•  LANGUAGE-ORIENTED  RUN  TIME  ENVIRONMENTS 

•  HARDWARE-CONTROLLED  RESOURCE  MANAGEMENT 

•  OBJECT-BASED  INTERFACES  AND  SERVICES 

KEY  CONCEPT: 
DOMAIN-BASED  PROTECTION 

•  INDEPENDENT  MODULE  ADDRESS  SPACES 

•  ADDRESS  SPACE  SWITCHING  ON  PROCEDURE  CALL 


•  CAPABILITY  ADDRESSING  AND  ACCESS  CONTROL 


KEY  CONCEPT:  OBJECTS  AS 
UNIFIED  DESIGN  FRAMEWORK 


•  INTEGRATING  HARDWARE  AND  SOFTWARE 

•  MINIMIZING  CONCEPUTAL  DIFFERENCES 

•  CLARIFYING  AND  SIMPLIFYING  OVERALL  DESIGN 


KEY  CONCEPT:  MULTIPROCESSING 


GENERAL  GENERAL  GENERAL  MAIN 

DATA  DATA  •••  DATA  MEMORY 

PROCESSOR  PROCESSOR  PROCESSOR  SUBSYSTEM 
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ELEMENTS  OF  THE  ARCHITECTURE 


•  OBJECT-BASED  ADDRESSING  AND  PROTECTION 

•  BASIC  COMPUTATIONAL  FACILITIES 

•  PROGRAM  EXECUTION  ENVIRONMENTS 

•  OBJECT-ORIENTED  PROGRAMMING  SUPPORT 

•  INTERPROCESS  COMMUNICATION 

•  SYSTEM  RESOURCE  MANAGEMENT 


A  CONCEPTUAL  VIEW  OF 
OBJECT  ADDRESSING 

ADDRESS 

SPACE  A  _ 


432  OBJECT  ADDRESSING  MECHANISM 
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432  PROCESSING 
UNIT 


SIMPLE  OPERAND  ADDRESSING 
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DOMAINS  AS  USER-DEFINED  OBJECT  TYPES 


PROCEDURE-FREE  REPRESENTATIONS  OF 
USER-DEFINED  OBJECTS 
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CARRIERS  ENQUEUE  WAITING  PROCESSES 


WAITING  PROCESS  OBJECTS 
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BLOCKED  PROCESS  OBJECTS 


A  MESSAGE-PASSING  MODEL  OF 
PROCESS  SCHEDULING 


1 


MESSAGE  PASSING  MODEL  OF 
PROCESSOR  DISPATCHING 


SHARED  AOORESS  SPACE 


K-  I  1 


iMAX  432  AND  THE  SILICON  OS 


ADA:  THE  IDEAL  IMPLEMENTATION 
LANGUAGE  FOR  432 


•  ADA  MATCHES  THE  432  DESIGN  METHODOLOGY 

-  BASED  ON  THE  CONCEPT  OF  OBJECTS 

-  SIGNIFICANT  SUPPORT  FOR  MODULARIZATION 

-  AIMED  AT  REDUCING  PROGRAMMING  COSTS 

•  ADA  CONSTRUCTS  MAP  THE  ARCHITECTURE  AND  OS 

OBJECT  OBJECT 

PACKAGE  DOMAIN 

ACCESS  ACCESS  DESCRIPTOR 

SUBPROGRAM  ACTIVATION  CONTEXT 

•  ADA-432  FEATURES  PROVIDE  DIRECT  ACCESS  TO  THE 
HARDWARE 

-  432  SPECIFIC  OPERATIONS  ARE  IN  ADA’s  STANDARD  MACHINE 
ACCESS  PACKAGE 

-  SIMPLE  432  EXTENSIONS  TO  ADA  SUPPORT  DYNAMIC  SYSTEMS 


I  CL  EFFORTS  IN  COMPUTER  SECURITY 
Tom  Parker 

Internal ional  Computers  Limited 


This  presentation  covers  a  subject  which  is  becoming  a  bit  of  a 
Cinderella  in  the  secure  computing  world.  I  am  talking  about  the  much 
criticized  business  of  making  a  real  life,  big  machine,  practical, 
commercially  acceptable  operating  system  as  secure  as  possible. 

I  am  talking  about  the  kind  of  system  for  which  the  use  of  formal 
verification  technology  is  beyond  the  state-of-the-art;  ior  which 
restructuring  along  the  TCB  lines  proposed  by  Grace  Nibaldi  must  be  very 
expensive,  and  for  which  there  are  no  absolute  guarantees  of  security,  a 
system  for  which  the  attainment  of  the  magic  Nibaldi  level  6  is  a 
fairytale  fantasy,  but  a  system  which  nevertheless  occupies  an  important 
niche  in  the  total  spectrum  of  secure  data  processing  requirements. 


SLIDE J. 

The  system  1  shall  be  talking  about  is  a  large  general  purpose 
operating  system  from  a  European  manufacturer.  It  is  called  VME/B,  and 
it  is  marketed  by  ICL  on  our  2900  range  of  computer  mainframes. 

As  some  of  the  audience*  here  today  may  not  know  much  about  ICL,  I 
think  I'd  better  start  by  giving  a  brief  description  of  who  we  are,  and 
give  a  bit  of  background  to  the  development  of  the  2900  series.  1  shall 
then  go  on  to  describe  the  hardware  architecture  of  2900,  concentrating 
of  course  on  those  features  that  are  most  relevant  to  security.  'MK/Ii  is 
the  largest  of  a  number  of  ICL  operating  systems  that  run  on  th . 
architecture;  it  is  a  system  that  has  received  a  lot  ot  attention  from 
the  point  of  view'  of  security  in  ICL  and  I  shall  be  describing  some  of 
its  protection  features.  It  has  also  been  the  target  for  much  of  the 
security  enhancement  work  that  has  been  undertaken  by  ICL,  mainly  with 
the  objective,  of  satisfying  the  needs  of  customers  with  espe<  laity 
stringent  security  requirements.  I  shall  outline  some  of  tins  work  at 
the  end  of  the  presentation. 
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"JCI."  stands  for  International  Computers  Limited,  and  not  onl\  is 
iCL  the  only  indigenous  GK  mainframe*  manufacturer,  but  also  we  tie  one  of 
the  few  to  produce  computers  with  an  architecture  f undunent a  1 1 v  ditlerent 
from  IBM's.  To  give  you  some  idea  of  the  size  ot  the  Comp an\ ,  our 
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turnover  last  year  exceeded  1.5  billion  dollars  and  we  employ  over  26,000 
people,  about  20,000  of  whom  are  in  the  UK. 

The  value  of  ICL's  world-wide  customer  base  is  well  over  4.5  billion 
dollars  in  86  different  countries.  Apart  from  the  ubiquitous  IBM  this  is 
the  biggest  customer  base  outside  America  and  Japan  of  any  computer 
manuf acturer . 

ICL  was  '‘ormed  in  1068  as  a  result  oi  a  merger  betwt-en  what  was  then 
two  major,  and  competing  British  computer  companies:  ICT  and  English 
Electric.  At  that  time  it  was  realized  that  the  new  Company  would  soon 
need  a  range  of  new  machines  to  replace  the  many,  varied  and  incompatible 
ones  inherited  from  the  merger  Also  of  course  these  inherited  machines 
had  architectures  and  a  hardware  technology  dating  from  the  50's  and 
early  60's.  Both  hardware  and  software  technology  had  moved  on  a  lot 
since  then. 

So  out  of  all  this  after  an  appropriate  gestation  period,  came  the 
first  of  the  2900  series.  This  was  a  revolutionary  rather  than  an 
evolutionary  step.  A  rare  thing  in  the  commercial  computer  world. 
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The  design  was  of  course  influenced  by  that  of  exist ’'ng  in-house 
systems  and  obviously  the  architectures  of  other  machines  in  the 
marketplace  at  the  time  were  also  examined,  for  example  a  number  of 
ML'LTICS  concepts  were  very  influential,  particularly  in  the  protection 
sphere,  where  some  aspects  still  represent  state-of-the-art,  even  12 
years  later. 

For  those  of  you  who  would  like  to  know  more  about  this  history,  1 
would  recommend  John  Buckle's  book  on  the  subject,  which  also  appears  in 
condensed  form  in  the  November  78  issue  of  the  ICL  Technical  Journal. 


SLIDES 

2900  ARCH ITECTURE 

So  what  kind  of  beast  did  we  produce?  Let's  have  a  look  at  some  of 
the  architectural  features  of  the  2900.  This  is  a  list  of  the  ones  we 
shall  look  at.  I'll  describe  each  one  then  bring  this  slide  back  and 
collect  them  altogether  at  the  end. 

Central  to  the  architecture  of  2900  are  the  complementary  concepts 
of  virtual  store  and  virtual  machines,  and  their  common  base  of  virtual 
address i ng . 
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All  addressing  is  in  terms  of  virtual  addresses  mapped  onto  real 
addresses  by  hardware  using  segment  and  page  tables.  The  real  addresses 
can  be  in  real  store  or  on  secondary  store  on  drum  or  disc.  In  order 
words,  we  have  a  straightforward  virtual  store  implement  at  ion .  bach 
process  runs  in  its  own  "virtual  machine"  in  which  it  has  its  own  unique 
local  segment  table  and  shares  a  public  segment  table  with  all  other 
virtual  machines.  It  can  optionally  also  have  "global"  segments  which  it 
shares  with  chosen  other  virtual  machines.  I  think  that  it  is  generally 
accepted  that  this  kind  of  hardware-supported  process  address-space 
separation  is  important  to  good  system  security. 
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The  primitive  instruction  code  makes  extensive  use  of  'descriptors' 
for  indirect  addressing.  A  descriptor  is  a  64-bit  entity  which  formally 
describes  an  item  of  information  in  store.  One  half  of  the  descriptor 
contains  the  base  address  of  the  item  being  described  in  terms  of  segment 
number  and  displacement.  In  other  words,  this  half  of  the  descriptor 
contains  a  'virtual'  address.  The  other  half  contains  information 
relating  to  the  unit  size  of  the  item,  the  number  of  units  it  contains, 
whether  modifiers  added  to  the  item's  address  should  be  appropriately 
scaled  or  not,  and  so  on.  Descriptors  are  also  typed  according  to  what 
kind  of  information  they  are  addressing.  This  slide  shows  a  "Descriptor 
Descriptor"  pointing  to  a  row  of  three  "Byte-Vector"  descriptors,  each  of 
which  is  pointing  at  a  bounded  area  of  virtual  store.  Some  other 
examples  of  descriptor  types  are  Code  Descriptors,  Semaphore  Descriptors 
and  System  Call  Descriptors.  One  obviously  important  'correctness' 
feature  present  in  the  2900  is  automatic  bound  checking  on  modification. 
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Next  in  the  list,  are  the  features  needed  to  control  basic 
input/output  and  other  primitive  privileged  operations.  The  totality  of 
addressable,  hardware  registers  is  called  the  "image  store".  This  divides 
into  two  parts:  the  visible  and  invisible  registers,  and  the  distinction 
between  them  is  critical  to  the  system's  security. 

Visible  registers  are  accessible  by  normal  unprivileged 
instructions,  and  consist  of  such  things  as  Program  Counter,  local 
namebase  pointer,  Weal  Time  Clock,  and  so  on.  Access  to  the  invisible 
registers  is  by  using  what  is  called  "image  store  operand  format,"  and 
this  requires  privilege. 

Access  to  the  invisible  registers  is  required  to  perform 
Input/Output  operations,  to  activate  a  now  process  and  to  perform  other 
privileged  functions. 

Privileged  status  is  obtained  only  by  a  hardware  interiupt 
mechanism.  When  the  VMK/B  Operating  System  is  present ,  such  interrupts 
cause  entry  to  the  most  trusted  part  of  the  oper.it  ing  system  (the 
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'Kernel'  of  VME/B ) . 
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A  process's  level  of  trustedness  is  defined  by  the  contents  of  an 
'invisible'  register:  the  Access  Control  Register,  called  ACR  ior  short. 
The  ACR  register  is  actually  a  part  of  the  Program  Status  Register  shown 
on  the  previous  slide.  The  level  of  trustedness  is  called  the  ACR  level. 
The  lower  the  value  of  its  ACR,  the  more  trusted  a  process  is. 

Segment  protection  occurs  in  that  on  access  to  store,  the  ACR  level 
of  the  process  and  the  mode  of  access  are  compared  with  access  permission 
fields  that  are  associated  with  each  segment.  "Change  Access"  on  the 
slide  refers  to  the  ability  to  change  the  access  permission  fields 
themselves.  There  is  also  an  Execute  Permission  bit  which  is  used  to 
prevent  the  accidental  execution  of  data. 

Entry  to  a  procedure  running  at  a  different  ACR  level  must  be  via  a 
hardware-supported  'system  call'  mechanism  which  polices  the  availability 
of  the  called  procedure  from  the  caller's  ACR  level.  An  important 
feature  of  the  mechanism  is  its  enforcement  of  entry  to  the  procedure  at 
the  proper  entry  point.  So  you  can  see  that  what  we  have  here  is  a  ring 
protection  system.  There  are  sixteen  possible  different  levels,  that  is: 
16  ACR  levels. 

Critical  to  the  security  of  the  system  is  the  proper  validation  by  a 
trusted  procedure  of  reference  parameters  passed  to  it  when  being  called 
by  less  trusted  code.  A  special  primitive  instruction  is  provided  for 
this  purpose  which  we  call  the  ’Validate’  instruction.  I  shall  be  saying 
more  about  parameter  validation  later. 

So,  let's  pause  for  a  minute  and  look  at  the  major  items  so  iar. 
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We  have: 

virtual  addressing,  supporting 
v  i  rtua 1  store  and 

virtual  machines  -  providing  protection  between  processes 
descriptors  with  automatic  bound  checking, 
a  protected  I  /()  mechanism; 

and  a  lh  level  t  ing  protection  system  with  an 
associated  mechanism  for  policing  the  transfer  oi  control 
between  the  rings  -  providing  protection  with  a  process. 


These  are  all  basic  arch  it ectura '  hardware  supported  features  present  in 
the  raw  machine. 
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1  should  quickly  mention  one  further  architectural  feature:  the 
"process  stack."  It  has  no  direct  security  connotations,  but  makes  such 
an  important  contribution  to  the  overall  flavour  of  the  2900  architecture 
that  it  would  be  misleading  to  miss  it  out. 

The  instruction  code  at  the  primitive  level  is  based  on  the  use  of  a 
LIFO  or  "Last  In  First  Out"  stack.  The  stack  is  used  for  parameter 
passing  and  local  name  space  purposes  and  each  Virtual  Machine  has  its 
own  stack.  Nested  procedure  calls  will  cause  the  usual  succession  of 
name  spaces  to  be  built  up  on  the  stack,  which  are  deleted  on  a  "last  in, 
first  out"  basis  as  the  procedures  exit.  We  have  found  the  stack 
mechanism  on  2900  to  be  an  elegant  and  natural  aid  to  the  procedure  call 
mechanism.  Those  then  are  the  main  architectural  features  of  the  2900 
series  machines.  When  it  was  introduced  it  was  quite  an  advanced  system 
for  its  time.  In  tact  many  of  ICL's  early  development  problems  stemmed 
from  the  fact  tiiat  we  were  breaking  new  ground  in  so  many  areas.  Even 
today,  operating  system  technology  in  commercially  available  systems  is 
only  just  catching  up  with  the  2900  architecture  which  forms  a  very 
adequate  basis  for  the  development  of  a  secure  operating  system. 
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One  such  development  is  VMK/B.  VME  stands  for  Virtual  Machine 
Environment.  B  stands  for  B. 

VMF./B  is  a  large  mixed  workload  operating  system  catering  for  Batch, 
Mult  i -Access  and  Transaction  Processing  applications. 

The  smallest  machine  on  the  2900  range  on  which  a  full  system  is  at 
present  intended  to  be  run  is  the  295t>,  though  there  are  subset  options 
that  can  run  on  a  smaller  machine.  Comparisons  are  difficult  but  the 
2956  is  very  roughly  equivalent  to  an  IBM  4331  Model  2,  or  somewhere 
between  a  DEC  VAX  11/750  and  VAX  11/780.  A  practical  full  VME/H  system 
including  typical  user  application  code  needs  a  real  store  size  of  at 
least  2  megabytes,  so  it's  a  big  operating  system. 

The  operating  system  divides  into  three  quite  distinct  parts, 
separated  by  error  handlers  as  shown  on  the  slide.  At  the  most  trusted 
level  is  Kernel,  which  handles  real  system  resources  like  store  and 
devices.  It  runs  mainly  'out  of  process'  on  a  public  stack  and  helps  to 
support  the  virtual  store/ v i rtua 1  machine  image  of  the  basic.  29(K 
arch  i  lecture . 

Director  is  responsible  for  the  handling  of  a  more  abstract  view  of 
the  system's  resources.  At  this  level  are  the  block  level  file  managers , 
and  the  major  security  related  operating  system  functions  like  the 
loader,  name  handler  and  privacy  controller.  Director  occupies  ACk 
levels  and  5. 

I ncontrol led  communication  between  virtual  machines  is  prohibited 
above  ADR  level  5  by  disallowing  public,  segments  with  write  access  keys 


6 


greater  than  ACR  5  and  by  controlling  the  availability  of  global 
segments . 

Level  7  to  9  contain  the  Above  Director  software  as  shown  on  the 
slide.  From  the  security  point  of  view  it  could  be  considered  as  a  sort 
of  "trusted  superstructure."  Above  ACK  9  is  the  real  enemy  -  the  user. 
Facilities  are  provided  tor  user  installations  to  structure  the  levels  at 
which  the  various  applications  run  within  ACR  levels  10  to  15.  and  these 
can  be  used  by  installation  management  to  cut  normal  unprivileged  users 
off  either  partially  or  completely  from  direct  use  of  the  facilities  of 
the  operating  system  if  so  required.  1  shall  say  a  bit  more  about  this 
later. 


Notice  that  unlike  in  some  contemporary  machines,  compilers,  and 
general  utilities  are  no  more  trusted  by  the  operating  system  than  user 
code  . 

All  operating  system  code  segments  are  established  with  a  write 
access  key  of  zero  and  so  all  operating  system  code  is  necessarily  pure. 
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The  slide  shows  a  typical  selection  of  operating  system  procedures 
and  VME/B's  use  of  the  system  call  mechanism.  The  small  boxes  are  the 
procedures.  I  have  drawn  them  at  their  execution  ACK  level.  The  lines 
w'ith  blobs  on  the  end  show  the  highest  ACR  level  from  which  they  can  be 
called. 

In  the  actual  system  the  vast  majority  cannot  be  called  at  all  from 
outside  their  own  level,  but  there  still  remains  a  substantial  number 
that  are  directly  callable  from  user  ACK  levels. 

The  proper  validation  of  parameters  passed  across  the  user /operat i ng 
system  interface,  is  well-known  to  be  critical  to  the  security  correctness 
of  operating  systems,  and  VMK/B  is  no  exception.  A  lot  of  time  and 
energy  has  been  spent  ('insuring  that  reference  parameter  validation  is 
complete.  In  particular  an  object  code  analysis  package  has  been  wi ittcn 
that  searches  out  discrepancies  for  manual  analysis  and  correction.  It 
examines  actual  loaded  code ,  and  ,<o  detects  flaws  that  might  be 
introduced  by  post  compilation  patches  or  repairs  which  at  that  stage 
have  been  fully  applied.  The  checking  is  therefore  as  near  to  the 
engine'  as  possible. 

Another  approach  has  been  to  reduce  the  number  of  procedures 
available  to  the  user  at  particular  secure  installations.  A  package  has 
been  produced  to  monitor  usage  of  system  code  with  a  view  to  making 
unused  interfaces  unava i 1 ab 1 e .  or  restructuring  the  availability  e: 
little  used  interfaces  on  particular  secuie  sites. 

The  package  has  a  very  low  performance  overhead  and  can  be 
permanently  left  in  the  system. 
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Installations  have  a  considerable  degree  of  control  over  operating 
system  called  is  defined  at  system  load  time  in  a  load  control  file 
interestingly  called  the  'recipe'  file,  and  this  file  is  amendable  by 
installation  management.  A  mechanism  also  exists  whereby  trusted  users 
can  access  a  smaller  number  of  additional  procedures.  The  availability 
of  these  more  powerful  interlaces  can  be  tailored  to  the  specific 
functional  requirements  of  the  chosen  trusted  user  classes.  Standard 
ones  are  for  example  Support  Engineers,  Operators,  or  the  System  Manager. 

There  are  in  fact  a  number  of  areas  in  VME/B  into  which  hooks  and 
options  have  been  put.  This  gives  installation  security  authorities  a 
great  deal  of  flexibility  in  deciding  on  what  they  want  for  their  system. 

Indeed,  the  extent  to  which  particular  secure  installations  can  bend 
VME/B  to  suit  their  individual  security  requirements  is  itself  a  major 
security  feature  of  VME/B. 

To  give  a  cruue  example,  a  class  of  multi-access  user  can  be  defined 
whose  only  commands  are,  say, 

INPUT 

EDIT 

COBOL  COMPILE 
COBOL  RUN, 

with  no  low  level  code,  or  direct  use  of  operating  system  interface  being 
allowed  at  all. 
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All  major  system  objects  are  recorded  in  a  central  filestore 
database  known  as  the  VME/B  Catalogue.  It  is  controlled  from  ACR 
level  5.  The  Catalogue  is  organized  in  terms  of  nodes  and  relationships. 
Entries  for  named  objects  are  located  at  nodes  which  are  connected  ny 
relationships.  Objects  catalogued  include  Devices,  Volumes,  Files  and 
other  specialized  VME/B  objects.  One  example  of  a  VMF.'B  object  is  shown 
on  the  slide  -  that  of  a  job  profile.  A  user's  access  to  job  profile 
nodes  detorrr.nes  the  kind  of  work  that  he  can  run  on  the  system. 

Privacy  controls  can  be  applied  to  all  of  these  objects  and  access 
can  be  constrained  on  a  general,  specific  and  hierarchic  basis.  A  wide 
variety  of  success  types  is  supported,  distinguishing  for  example  between 
access  to  a  file's  contents  and  access  to  its  name  and  description.  All 
attempted  privacy  violations  are  logged  to  a  security  journal.  An 
installation  can  arrange  that  such  messages  are  output  immediately  to  the 
journal,  or  held  in  a  buffer  and  then  output  when  the  bill  ter  is  lull. 

Particularly  important  in  the  access  control  features  is  the 
ability,  by  means  of  device  access  settings,  to  prevent  users  oilier  than 
chosen  individuals  accessing  the  system  using  a  particular  terminal. 
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Alternatively  all  users  except  named  individuals  can  be  allowed  to  use  a 
particular  device.  This  is  useful  for  example  in  preventing  the  system 
manager's  username  being  used  at  all  terminals  except  a  particular  one. 
Such  protection  would  of  course  be  additional  to  the  protection  provided 
by  the  System  Manger's  password. 
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Users  are  identified  by  a  catalogued  username  which  can  take  one  of 
three  security  levels:  low,  medium  and  high.  A  high  security  user  may 
not  submit  batch  jobs;  high  and  medium  security  users  must  subrr.it  a 
password  when  logging  in  for  a  multi-access  session. 

Multi-access,  or  MAC  passwords  can  be  up  to  12  characters  long  and 
are  irreversably  encrypted  when  stored  at  the  catalogue  user  'node'  for 
login  comparison.  In  this  way  sight  of  the  stored  version  is  made 
useless  to  the  would-be  penetrator. 

The  login  sequence  is  very  tightly  controlled. 

The  would-be  MAC  user  once  having  started  the  sequence  will  either 
obtain  legitimate  access  within  a  certain  time  or  cause  the  terminal  to 
be  locked  out  with  an  immediate  security  alarm  at  the-  Master  Operator's 
terminal.  Line  breakdowns  for  example  at  this  stage  cause  security 
violations.  So  pulling  the  plug  out  won't  do  him  any  good. 

A  reverse  password  facility  is  also  available  with  which  the  system 
can  be  made  to  identify  itself  to  the  user. 

Another  feature  is  program  controlled  access  to  files  using  .,CR 
levels.  By  this  means,  installation  management  can  force  access  to 
chosen  files  through  installation  written  software  which  can  perform 
auxiliary  protection  checks,  for  example  file  passwords. 

ICL  markets  the  IDMS  Database  system  (developed  from  the  Cull  inane 
Corporation  designl.  By  making  use  of  ACR  access  control,  IDMS  has 
become  one  of  the  few  secure  databases  systems  commercially  available 
today . 
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Well,  these  are  some  of  the  main  VMK/B  security  features.  Here  they 
are,  collected  together. 

We  have : 

full  use  of  the  ACR  ring  protection  system  both 
by  the.  operating  system  and  potentially  by  the 
installation  security  management 


in  store  code  unmodi fiable  -  pure  code 
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extensive  installation  tailoring  facilities  and 
hooks 

central  access  control  to  all  system  objects 


. . .  and  so  on  as  shown  here. 

And,  one  final  thing  on  VME/B's  features: 

We  have  just  started  to  investigate  the  possibility  of  the  provision 
of  the  ability  to  police  a  mandatory  security  policy,  and  it  is  looking 
reasonably  straightforward  to  integrate  into  the  existing  security 
structure . 


DESIGN  AND  PRODUCTION  METHODOLOGY 
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From  our  experience  of  producing  earlier  operating  systems  we  realized 
at  the  outset  that  one  cannot  simply  treat  an  operating  system  as  a 
collection  of  programs  and  then  farm  out  the  development  of  these  programs 
to  separate  groups  of  programmers,  hoping  that  they  will  all  fit  nicely 
together  when  the  doomsday  of  integration  approaches. 

So  we  designed  and  built  a  system  called  CADES. 
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CADES  is  a  methodology  and  a  set  of  mechanisms  to  support  that 
methodology.  The  VME/B  design  is  top  down  data  driven  and  hierarchic,  and 
the  prime  objective  of  CADES  was  that  the  product  was  designed  before  it 
was  implemented.  We  all  know  how  difficult  that  is  in  the  pressures  of  a 
commercial  production  environment. 

The  design  methodology  is  then  supported  by  mechanisms  which  may 
consist  either  of  well-established  rules  for  human  actions  and  interactions 
(we  call  them  the  CADES  Design  Rules),  or  software  products  to  be  used  as 
tools  by  the  designers  and  implementors. 

The  hierarchies  of  modules  and  data  structures  with  their  attributes 
and  relationships  are  stored  in  the  CADES  database,  and  this  forms  an 
authorized  description  of  the  product  as  it  is  being  developed.  The  final 
content  of  the  database  is  the  product  itself  so  there  is  no  break  in 
continuity  between  design  and  production.  The  ultimate  objective  of  CADES 
was  to  support  the  total  software  development  cycle  from  initial  design 
right  through  to  successive  releases  of  the  system  w'ith  supporting 
documentat ion . 
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VMF./B  is  a  result  extensively  documented  in  a  structured  manner  in  a 
microfiched  multi-volume  library  known  as  the  "Project  Log."  For  example, 
systems  wide  cross  reference  listings  of  data  object  usage  and  procedure 
calling  structure  are  available,  and  can  be  automatically  reproduced  for 
all  new  releases  using  the  CADES  database. 

A  very  good  description  of  CADES  can  be  found  in  tin'  Ma\  1981.'  edition 
of  the  ICL  Technical  Journal. 

It  is  important  to  say  at  this  point  that  CADES  does  not  have  the 
richness  of  design  language  nor  the  degree  of  formalization  enjoyed  by  the 
formal  languages  that  everybody  here  is  familiar  with.  It  was  never 
intended  to  be  used  as  a  basis  for  later  design  correctness  verification. 

Nevertheless,  ICL  finds  CADF.S  an  invaluable  practical  tool,  and  we  are 
continuously  developing,  enhancing,  and,  possibly  most  importantly,  usnig 
it . 


The  implementation  language  of  VME/B  is  called  S3.  1  haven't  the 

faintest  idea  why.  It  is  a  development  of  ALGOL  68.  In  other  words,  it  is 
a  wel 1 -structured  high  level  language  with  moderately  strong  typing  and  a 
block  structure  very  suitable  for  the  2900  stack  architecture. 

The  production  teams,  however,  actually  Code  VMF./B  in  an 
implementation  level  enhanced  System  Description  Language,  or  SDL,  which  is 
automatically  converted  into  S3  source  by  the  CADES  system.  Niggling 
little  things  like  complex  data  mode  declarations,  interfaces  parameter 
specifications,  constant  and  failure  code  values,  macro  expansions,  and  so 
on,  are  thereby  automatically  looked  after  by  CADES. 
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The  slide  shows  an  example  of  some  implementation  level  SDL.  It  is 
actually  some  SDL  for  a  module  which  is  part  of  the  CADF.S  system  itself. 

We  now  use  CADES  to  design  and  build  CADES! 

I  won't  describe  the  slide  in  detail,  it's  there  just  to  give  you  a 
flavour  of  the  language.  At  the  top  are  the  EXT  and  10  sections  which  list 
the  procedures  that  this  procedure  calls,  and  the  external  data  areas 
referenced.  The  interface  definitions  and  modes  of  these  items  are  of 
course  all  held  in  the  CADES  database.  The  asterisks  at  the  beginning  oi 
some  of  the  lines  in  the  FUNCTION  section  trigger  oft  various  substitution 
and  validation  actions  that  occur  when  the  system  is  converting  this  code 
into  S3. 


The  existence  of  centrally  held  definitions  of  svstem-wide  objects 
like  data  mode  declarations  and  interface  specs  and  so  on  automat i cn 1 1 y 
reduce,  of  course,  the  problem  of  mismatches  in  all  of  these  areas. 

An  important  current  CADES  development  is  the  provision  oi  an  enhanced 
SDL/PASCAL  back  end.  ICL  holds  the  view  that  whenever  possible,  soltware 
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products  should  be  written  in  high  level  languages,  and  PASCAL  is  one  that 
we  have  chosen  to  be  heavily  used,  particularly  in  the  production  of 
non-mainframe  software.  The  compiler  has  been  structured  to  enable  a 
number  of  different  target  object  codes  to  be  produced.  In  developing  the 
PASCAL  aspect  of  CADES  we  have  incorporated  a  number  of  the  good  features 
of  the  ADA  development  environment,  for  example  the  separation  of  package 
specs  from  package  bodies. 

One  final  random  point  of  interest,  to  do  with  the  CADES  design  there 
are  no  "GO  TO's"  in  VME/B,  well,  hardly  any! 
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I  would  just  like  to  finish  off  now  with  a  brief  survey  of  some  of  the 
additional  security  work  that  has  been  and  is  being  undertaken  on  VME/B. 

Obviously  some  of  our  customers  have  special  security  requirements,  so 
the  first  thing  to  say  is  that  a  substantial  number  of  extra  security- 
features  have  been  developed  to  satisfy  them.  Another  objective  has  been 
to  'harden'  VME/B  not  only  from  the  point  of  view  of  extra  facilities  but 
also  from  the  point  of  view  of  correctness. 

Of  course  everybody  benefits  from  correctness  improvements,  but  also 
some  of  the  additional  facilities  have  since  become  standard  product  line 
items . 


To  further  our  'correctness'  objective,  we  have  been  subjecting  the 
primitive  architectural  features  and  low  level  operating  system  features  to 
'theoretical'  analysis,  backed  up  where  appropriate  by  actual  tests.  This 
is  a  continuous  process,  since  new  releases  of  the  operating  system  are 
continually  providing  new  areas  to  be  examined.  For  this  reason  wo  are 
attempting  to  automate  the  analysis  as  much  as  possible. 

Most  of  the  tools  developed  in  this  work  are  incorporated  into  a 
"security  tost  package"  which  also  incorporates  tests  of  the  standard  user 
visible  security  facilities.  The  package  is  now  being  applied  during  the 
acceptance  testing  phase  of  each  new  release  of  the  product. 

n  also  maintain  a  close  relationship  between  ourselves  and  our  major 
secure  users  and  conduct  regular  meetings  devoted  to  examination  and 
discussion  of  security  issues  at  both  technical  and  non-t ecinu ca 1  levels. 

Every  so  often,  we  stand  back  and  look  at  the  overall  security 
structure  of  VME/B.  One  current  example  is  a  development  of  the  security 
control  object  dependency  graph  idea  developed  by  Linde  at  SDC,  which  we 
hope  will  be  found  useful  in  identifying  areas  requiring  most  attention. 
Another  example  is  an  examination  of  the  feasibility  oi  restructuring  the. 
operating  system  in  minor  ways  to  enable  the  control  of  security  to  be  more 
localized  (note  I  might  add  to  the  extent  of  a  security  kernel's 
loca 1  izat ion). 
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An  early  hardened  version  of  VME/B  was  subjected  to  a  'tiger  team' 
attack  a  few  years  ago  with  encouraging  results.  In  that  attack,  the 
system  demonstrated  a  reasonable  degree  of  security  in  that  the  attack  team 
failed  to  achieve  their  major  penetration  objectives. 

I  should  add  that  at  the  time  there  were  a  small  number  of  known 
defects  declared  as  'no  go',  areas,  and  others  that  had  to  be  compensated 
for  'by  appropriate  rather  restrictive  procedural  controls.  We  have,  of 
course,  since  cleared  these  defects. 

I  would  be  foolish  though  to  claim  that  the  system  is  now  therefore 
totally  secure,  but  it  at  least  shows  that  the  claim  that  it  is  'easy'  to 
penetrate  a  modern  well  structured  commercial  operating  system  has  to  be 
examined  very  carefully.  The  great  majority  of  successful  penetrations 
have  been  by  teams  consisting  of  top  class  systems  penetration  specialists. 
It  has  been  said  that  the  ideal  qualification  for  a  member  of  a  penetration 
team  is  that  he  should  be  "a  negative  thinking  anarchist  with  an  IQ  of  150 
and  the  patience  of  Job."  Such  people  are  hard  to  find.  What  is  easy  for 
them  might  well  prove  impossible  for  ordinary  mortals. 

A  system  that  has  been  penetrated  by  specialists,  and  VME/B  might  well 
be  one  day,  cannc '  be  dismissed  as  being  insecure.  Security  is  not  a 
binary  property  that  is  either  present  or  not,  and  this  has  of  course  been 
clearly  recognized  in  Grace  Nibaldi's  valuable  work  on  this  subject. 
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Well  that's  about  it.  As  you  can  see  we  take  a  pragmatic  approach  to 
security;  it  has  to  be  pragmatic  on  a  system  as  large  as  VME/B.  We  make  no 
claims  of  absolute  security.  All  we  can  do  is  fill  as  many  holes  in  the 
colander  as  our  expertise  and  the  state-of-the-art,  allows. 

The  architectural  bedrock  on  which  VME/B  lies  is  sound.  The  operating 
system  itself  has  been  produced  using  modern  software  engineering 
techniques,  and  the  VME/B  user  has  always  been  considered  'malicious'!  We 
know  of  no  comparable  but  more  secure  system. 
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PSR 

PROGRAM  STATUS  REGISTER 

RTC 

REAL  TIME  CLOCK 

LSTB 

LOCAL  SEGMENT  TABLE  BASE 

OR 

DESCRIPTOR  REGISTER 

PSTB 

PUBLIC  SEGMENT  TABLE  BASE 

ACC 

ACCUMULATOR 

ETC 

ETC 

$ 

s 

EXTERNAL  DEVICE  REGISTERS 

) 

( 

ETC 

1 

ICL  PROTECTION  LEVELS 

•  ACCESS  CONTROL  REGISTER  (ACR) 

•  SEGMENT  ACCESS  CHECKS 

-  READ  ACCESS 

-  WRITE  ACCESS 

-  CHANGE  ACCESS 

-  EXECUTE  PERMISSION  BIT 

•  SYSTEM  CALLS 

-  CALLING  ACR  LEVEL  CONTROLS 

-  ENFORCED  ENTRY  AT  PROPER  ENTRYPOINT 

-  HARDWARE  SUPPORTED  PARAMETER  VALIDATION 


FEATURES  OF  THE  2900 
ARCHITECTURE 

•  VIRTUAL  ADDRESSING 

•  DESCRIPTORS 

•  IMAGE  STORE  AND  INPUT/OUTPUT  CONTROL 

•  ACR  LEVELS  AND  THE  VALIDATE  INSTRUCTION 

•  SYSTEM  CALL  MECHANISM 

•  THE  STACK 
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^  MAJOR  VME  B  SECURITY  FEATURES 

•  STRUCTURED  USE  OF  ACR  PROTECTION  WITH 

•  KERNEL 

•  DIRECTOR 

•  ABOVE  DIRECTOR 

•  SUPERSTRUCTURE 

•  SUPERSTRUCTURE  (USE R'S  CODE)  SUBDIVIDABLE 
BETWEEN  6  ACR  LEVELS 

•  PURE  CODE 

•  INSTALLATION  ABILITY  TO  DEFINE  WHICH  O/S 
FACILITIES  ARE  TO  BE  AVAILABLE  TO  WHICH 
USERS 

•  ADDITIONAL  INSTALLATION  HOOKS 

•  CENTRAL  TOTAL  ACCESS  CONTROL  VIA  FILESTORE 
CATALOGUE  OF  SYSTEM  OBJECTS 

•  LOGGING 

•  STRINGENT  USER  AUTHENTICATION  PROCESS 

•  REVERSE  PASSWORDS 

•  INSTALLATION  PROGRAMMABLE  FILE  ACCESS 
CONTROLS 


Computer 

Aided 

Development  and 

Evaluation 

System 


^  CADES 

CHARACTERISTICS 

•  A  METHODOLOGY  AND  A  MECHANISM 

•  TOP  DOWN,  DATA  DRIVEN,  HIERARCHIC  DESIGN 

•  FORMAL  CAPTURE  OF  DESIGN  ON  AN  IDMS 
DATABASE 

•  COMPLETE  DEVELOPMENT  CYCLE  SUPPORT 

•  SDL  LANGUAGE 


ICL  FURTHER  SECURITY  WORK 

•  ADDITIONAL  SECURITY  FEATURES 

•  THEORETICAL  ATTACK 

•  SECURITY  TEST  PACKAGE 

•  REGULAR  REVIEWS  OF  USER  REQUIREMENTS 

•  SECURITY  STRUCTURE  APPRAISAL 

•  ATTACK  EXERCISE 


CNOSIS :  A  PROGRESS  REPORT 

BOB  COLTEN 
TYMSHARE 

Thank  you,  Steve.  We  must  have  done  something  right  last  year  to  get 
invited  again. 

Before  my  prepared  remarks,  I'd  like  to  briefly  comment  on  the  sub¬ 
jects  raised  by  the  preceeding  speakers:  We  fully  agree  with  the  mes¬ 
sage  expressed  by  Steve,  by  Terry  Cureton,  and  others.  You  have  to 
walk  before  you  run.  We  also  agree  with  Axel  Vidtheldt  that  availabil 
ity  is  a  part  of  security;  and  with  CDC  that  you  can't  forget  perform¬ 
ance  or  customer  need.  With  that,  let  me  proceed  to  this  presentation 

This  year  it  is  our  intention  to  bring  you  up  to  date  on  the  progress 
we  have  made  since  last  years  presentation. 


For  those  of  you  wno  weren't  here  last  year,  we'll  briefly  review 
Gnosis . 

This  will  be  only  the  25C  tour.  Then  we'll  tell  you  about  the  bench¬ 
mark  . 

.  Why  we  selected  it 
.  How  it  was  implemented 
.  What  was  the  performance 
.  We'll  tell  you  what  we  learned  and.... 

Where  we  are  going  from  here  and  why 

Then  Norm  Hardy,  the  Architect  of  Gnosis  will  discuss  some  of  our  con¬ 
cerns  with  the  mechanisms  and  approaches  of  the  secure  system  evalua¬ 
tion  effort. 
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.  We  disclosed  Gnosis  to  this  audience  at  the  third  DOD 
security  initiative  seminar. 

Gnosis  was  started  by  Tymshare  as  an  in-house  research 
program  in  19^75. 

It  is  a  capability  based  operating  system  designed  to 
run  on  370  type  architecture .  It  was  started  by  a 
tiny  team  which  has  expanded  to  a  small  team  which 
now  consists  of  six  people. 

The  Gnosis  design  objectives  were  and  still  are  to: 

1.  Protect  proprietary  applications,  both  programs  and 
data. 

2.  Provide  a  high  performance  environment  for  transaction 
oriented  applications. 

3.  Simplify  and  reduce  the  cost  of  maintaining  applications. 

4.  Provide  an  operating  environment  in  which  applications 
can  be  easily  maintained. 

5.  Improving  programmer  productivity  in  developing  new 
applications . 

6.  Provide  a  facility  for  developing  fault  tolerant  appli¬ 
cations  . 

In  summary,  we  wanted  to  develop  a  product  to  enable  us  to  enter  new 
markets.  An  operating  system  that  is  easy  to: 

1.  Learn  3.  Debug 

2.  Program  4.  and  Protect 
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For  those  of  you  who  weren't  here  last  year,  what  follows  is  the 
25t  tour. 

First,  let  me  briefly  contrast  the  Gnosis  architecture  with  the 
architectures  of  systems  which  we  are  all  familiar  wi th  and  love 
dearly . 

In  most  existing  systems,  applications  are  located  in  the  same 
memory  space.  On  the  slide  that  is  shown  on  the  left  side,  stat 
pack  are  all  in  the  same  space.  If  one  part  of  the  application 
has  a  bug  in  it,  it  is  not  unlikely  that  it  will  impact  the  entire 
application  or  even  other  applications. 

This  type  of  breakdown  is  not  only  inconsiderate  but  downright 
rude.  It  also  tends  to  actively  promote  paranoia. 

In  Gnosis,  we  keep  not  only  applications  but  components  of  appli¬ 
cations  separated  in  separate  domains.  In  Gnosis,  each  element 
can  be  totally  isolated  from  every  other  element.  Each  of  these 
separate  elements  is  a  domain.  The  only  way  a  user  or  another 
program  can  access  a  domain  is  through  an  explicitly  authorized 
capability . 

If  you  want  to  know  more  about  Gnosis  you  can  find  more  in  last 
years  proceedings  or  the  Mitre  evaluation  or  write  to  me  or  Norm 
at  Tymshare. 


Let  me  now  briefly  contrast  our  situation  today  with  our  situation 
when  we  last  met  in  1980. 

Today  our  development  objectives  are  different  from  those  we  had 
in  1980. 

At  that  time  we  were - 

.  Looking  for  external  applications 
Looking  for  some  kino  of  support 


We  obtained  moral  support  from  the  evaluation  center  team....  and 
this  support  has  been  a  factor  in  motivating  us  to  accelerate  the 
Gnosis  development  effort.  More  about  the  contribution  of  the  evalu¬ 
ation  center  team  from  Norm. 

What  we  are  focusing  on  now  are  internal  applications.  We  are  not 
looking  for  external  financial  support. 

We  are  now  focusing  on: 

Developing  new  tools  to  facilitate  application  development 
Prouucing  documentation  to  help  users  implement  applica¬ 
tions  and  actually  implementing  new  application,  as  well  as, 
Measuring  the  performance  of  the  new  applications. 


Now  I'd  like  to  briefly  talk  about  the  benchmark. 

As  you  probably  know,  one  of  the  most  frequently  cited  reasons  for 
not  using  capability  based  systems  in  the  past,  was  that  their  per¬ 
formance  was  rotten. 

We  therecc.t,  had  to  find  an  application  that  was  both  real,  as  well 
as  typical  of  a  class  of  applications  in.  which  many  users  performed 
a  small  number  of  activities  simultaneously. 

We  wanted  the  test  to  be  a  multi-purpose  test.  The  individual  se¬ 
lected  to  do  the  evaluation  was  someone  outside  the  project  who  works 
for  another  division.  The  management  of  that  division  wanted  to  find 
out  if  Gnosis  would  run  the  kinds  of  applications  they  wanted  to  im¬ 
plement  . 

.  Thus  we  and  they  both  wanted  to  test  the  reliability  of 
the  system  under  stress. 

We  both  wanted  to  know  how  the  system  would  perform  under 
various  loads. 

They  wanted  to  know  if  Gnosis  had  the  functionality  to 
run  their  applications. 

They  were  concerned  that  Gnosis  was  .So  different  that 
normal  people  couldn't  use  it. 


They  wanted  to  find  out  how  good  the  documentation 
really  was,  namely,  could  their  development  people 
use  it. 

They  also  wanted  to  know  how  much  sharing  was  feasible 
and  how  easy  it  was  to  implement  in  an  application. 
Finally  they  didn't  want  to  spend  a  lot  of  money  or  time 
to  find  out  if  the  system  was  viable  and  useful  on  an 
application  development  environment. 

.  And,  we  wanted  an  application  that  was  fun  to  implement. 

Because  of  all  these  reasons,  we  selected  "Adventure",  a  program 
written  in  PL/1,  as  the  first  test  program  to  be  implemented  in  Gnosis. 
"Adventure"  is  a  game  similar  to  "Dungeons  and  Dragons"  with  a  spec¬ 
ific  cave  called  the  collossal  cave. 


Now  I'd  like  to  show  you  what  functions  were  involved  in  building  tin' 
selected  application  and  how  much  code  you  need  to  trust. 

This  part  of  the  system  predates  adventure  and  this  is  the 
only  part  needed  to  implement  the  adventure  application. 

It  consists  of  the  kernel  and  two  separate  domains,  the 
terminal  interface  and  the  receptionist. 

The  kernal,  unlike  most  familiar  operating  systems,  is  small  and  very 
simple;  it  functions  more  as  a  control  program  rather  than  as  a  con¬ 
ventional  operating  system.  It  runs  in  supervisor  mode,  it  is  un- 
swappable.  The  kernel  maintains  the  extended  machine  archi lecture , 
provides  the  basic  building  blocks  and  performs  operations  on  them 
on  behalf  of  the  user.  In  Gnosis,  capabilities  and  data  are  isolated 
from  each  other  so  that  capabilities  which  only  the  kernel  can  access 
directly  cannot  be  forged  or  manipulated  without  authority.  We  wanted 
to  test  the  kernel  under  stress. 

The  terminal  interface  system  provides  the  path  for  a  terminal  to 
communicate  with  the  adventure  game;  it  converts  ASCII  code  to  I.BDIC 
and  CBDIC  to  ASCII. 

The  receptionist  verifies  the  identity  of  the  caller  and  the  dost  inn- 


tion  on  the  domain  that  is  being  called. 


Next,  we  built  the  adventure  domain  and  hooked  it  to  the  terminal 
interfact  domain. 

The  adventure  domain  contained  the  same  PL/1  program  we  ran  under 
CMS. 


There  was  an  unresolved  situation  at  this  point.  When  the  line  hung 
up  we  were  left  hanging,  so  we  built  the  line  monitor  to: 

A)  .  Recognize  the  event 

B)  .  Take  the  appropriate  action 

Well,  in  the  crudest  sense,  this  is  all  you  need  to  have  a  single 
adventure . 

But,  we  assume  that  like  most  people,  this  audience  is  jaded  and  huvinu 
developed  a  taste  for  adventure  you  would  like  to  repeat  the  experience 
and  maybe  have  some  friends  join  you  in  the  game. 


The  slide  shows  that  if  you  want  more  than  one  adventure,  you  need 
to  duplicate  the  adventure  and  the  line  monitor  domains. 

It  is  importanc  to  point  out  however,  tnat  each  line  monitor  and  each 
adventure  share  most  of  their  code  and  their  data  in  read  only  mode. 

Thus,  when  more  than  one  player  plays  simultaneously,  it  is  necessary 
to  create  multiple  instances  of  adventure.  Code  is  shared  in  each 
instance  of  adventure  between  the  terminal  interface  and  the  recep¬ 
tionist. 


U  L 


The  adventure  domains  can  also  share  data  which  is  common  to  al!  users 
For  example,  the  description  of  the  cave. 

Thus,  the  entire  amount  of  storage  space  required  for  each  instance 
of  adventure  is  only  10  pages  of  real  memory  per  user,  most  of  it  is 
PL/1  variable  storage.  An  interesting  note--the  adventure  program 
was  not  modified  to  run  on  Gnosis  even  though  it  was  not  designed 
'for  sharing. 


To  build  the  multiple  instances  of  adventure  and  the  line  monitor,  and 
to  implement  policy  of  what  to  do  when  a  line  disconnects,  a  new  mech¬ 
anism  had  to  be  built.  This  mechanism  we  called  the  adventure  control 
ler . 

The  adventure  controller  creates  more  instances  of  adventure,  gives 
them  keys,  (no  one  else  has  keys),  namely  rights  to  access. 

The  adventure  controller  also  implements  the  policy  for  disconnecting 
terminals.  When  a  line  is  cropped,  the  line  monitor  notifies  the  ad¬ 
venture  controller.  The  adventure  controller  then  destroys  the  in¬ 
stance  of  adventure  and  reclaims  all  resources  owned  by  that  instance. 

In  addition  to  its  existing  functions,  the  adventure  controller  could 
be  used  to : 

.  Monitor  resource  consumption  by  each  user. 

.  Insert  debugging  tools. 

.  Insert  auditors  for  each  user. 


As  is  perhaps  more  evident  in  this  slide,  the  entire  structure  of 
adventure,  operating  within  the  Gnosis  environment,  is  very  simple. 
A  total  of  only  600  new  lines  of  code  had  to  be  written  to  niuke  it 
work.  500  lines  for  the  adventure  controller  and  100  lines  for  the 
line  monitor.  In  this  application  one  must  trust  the  kernel,  the 
terminal  interface,  the  receptionist,  and  the  adventure  control  let 
and  nothing  else. 


M-; 


There  is  no  operating  system  as  such  which  needs  to  be  trusted. 

No  virtual  machine 
No  command  language 
No  loading  of  programs 
No  file  system 
No  editor 

No  system  libraries 

Another  way  of  saying  this  is  that  when  playing  adventure  in  the 
Gnosis  environment,  "The  tail  does  not  wag  the  dragon."  If  Murv 
Shaefer  were  here,  he'd  say  that  was  a  tvoll  remark.  I  would  call 
him  a  bad  gnome. 


Now  that  you  know  the  architecture  of  the  adventure  benchmark,  let's 
look  at  how  long  it  took  to  implement  it. 

In  reality,  the  whole  thing  took  a  little  over  one  month  ,  if  you 

don't  count  the  first  month  to  get  oriented. 

It  took  1  man  week  to  do  the  controller 

'  the  line  monitor  and 

the  linkages 

and  two  more  man  weeks  to  do  the  multiple  version  of  adventure.  Then 
two  more  man  weeks  to  do  the  driver  and  the  scripts. 

Now  I'd  like  to  share  with  you  some  of  the  comments  made  by  the  devel¬ 
oper  of  the  benchmark  in  his  report  to  his  manager.  The  developer  is 

a  senior  applications  programmer.  Although  he  had  experience  on  many 
different  operating  systems,  he  haS  no: 

.  Capability-based  system  experience 
.  Gnosis  experience 

Experience  with  Gnosis  debugging  tools 
.  Prior  contact  with  the  Gnosis  team 
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GNOSIS  FUNCTIONALITY 


*  "Application  programmers  can 
learn  to  use  Gnosis  in  a 
relatively  short  time" 

*  "PL/1  programs  can  he  run 
under  Gnosis  with  very 

little  source  code  modification 
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He  also  noted  a  few  shortcomings: 

Documentation  as  presently  available  is  unfit 
for  man  or  beast. 

.  System  still  needs  work. 


Now  let's  look  at  the  results  of  the  benchmark. 

First  note  the  CMS  baseline:  We  used  CMS  because  it  was  avail¬ 
able.  Note:  The  vertical  axis  should  read  cumulative  or  total 
transaction  rate. 

The  test  was  conducted  on  a  370/158  MOD  I  with  5  megabytes  of 
memory  located  in  Dallas. 

A  transaction  generator  was  used  to  gei  erate  one  transaction  per 
second  per  user.  (That  is  shown  by  the  45  degree  line.) 

Each  CMS  transaction  needed  77  pages  of  memory  per  user  and  used 
up  150  milliseconds  of  CPU  time  allowing  r.  maximum  of  6.4  trans¬ 
actions  per  second. 


In  this  slide,  we  use  the  CMS  line  for  comparison.  We  ran  3  tests 
on  subsequent  weekends. 

.  The  1st  test  labeled  6/1/81  looked  pretty  bad. 

.  In  the  2nd  test  on  6/7/81,  wo  reduced  resources 
required  for  each  transaction. 

.  The  original  Gnosis  version  used  PL/1  refmatted  I/O 
to  write  each  line  on  the  terminal. 

PL/1  terminal  I/O  took  up  more  than  half  the  CPU  cycles.  We  wrote 
a  subroutine  to  replace  the  PL/1  language  cn  1  1  to  a  subtout  i  tie. 


Compatable  to  the  one  is  CMS. 


Test  2  performance  dropped  off  precipitously  due  to  thrashing 
(fixed  tables  in  kernel  were  not  balanced). 

In  test  3,  on  6/13/81,  we  understood  and  partially  resolved 
thrashing  by  better  balancing  of  tables  in  the  kernel. 

While  it  may  appear  that  Gnosis  and  CMS  performed  about  equally, 
it  is  important  to  note  that  the  CMS  tests  were  running  with  1001 
CPU  utilization  while  Gnosis  tests  ran  with  much  excess  CPU  capac¬ 
ity. 


The  6/13/81  line  in  this  slide  shows  what  the  total  transaction 
rate  would  have  been  if  the  transaction  driver  had  been  able  to 
run  fast  enough  to  saturate  the  CPU. 

At  this  point,  we  stopped  making  changes  in  the  system  since  we 
had  met  our  objective  to  beat  CMS. 

i/e  are  now  convinced  that  we  can  further  improve  Gnosis  perform¬ 
ance  and  that  Gnosis  can  be  competitive  with  other  I  M  transaction 
systems . 


We  are  aware  of  many  other  improvements  which  could  be  made  by 
reducing  system  overhead  as  well  as  the  cost  per  transaction. 

The  top  line  in  this  figure  could  be  achieved  with  1  man  month 
of  work  to  reduce  system  overhead  by  removing  additional  thrashing 
bottlenecks  in  the  kernel. 

In  addition,  we  could  increase  the  transaction  rat  another  sQ- 
if  we  optimized  terminal  transactions  by  developing  a  high  perform¬ 
ance  terminal  interface'  .and  by  optimizing  adventure  to  allow  even 
more  sharing. 
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These  actions  would  take  2  additional  man  months  and  would  reduce 
transaction  time  to  30  MS,  reduce  memory  per  transaction  to  10 
pages  and  yield  30  transactions  per  second  on  a  370/158  CPU.  On 
an  IBM  3033  this  would  mean  a  potential  of  between  100  and  150 
transactions  per  second. 

This  is  comparable  to  all,  but  the  fastest  IBM  transaction  process¬ 
ing  systems. 


Tymshare  is  increasing  the  level  of  support  for  Gnosis.  Kc  have 
been  authorized  to  hire  more  people  immediately. 

Gnosis  is  moving  from  R  &  D  to  development  status. 

We  have  two  applicatic  is. 

The  first  is: 

*  A  switch  which  is  designed  to  enable  users  to  access 
applications  which  run  on  multiple  computers  without 
effort  or  awareness  on  the  users  part. 

The  second  is: 

*  A  transaction  processing  system  for  a  transportation 
agency  which  will  be  continuously  updated  and  accessed 
by  many  users  simultaneously. 

In  summary. . . .  what  we  plan  to  do  during  the  next  year  is  the 
following : 

*  Implement  more  complex  systems. 

*  Have  a  system  which  is  continuously  and  routinely 
operational . 

*  Develop  tools  to  facilitate  the  implementation, 
debugging  monitoring  and  operatinq  the  new  applica¬ 
tions  . 

*  Insure  that,  the  now  tools  are  general  purpose  and 
that  they  enhance  programmer  productivity  perform¬ 
ance  and  the  reliability  of  Gnosis. 
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Finally,  we  are  now  convinced  that  Gnosis  will  evolve  into  a 
system  which  will  be  ready  for  general  use  in  two  to  three  years. 

It  is  important  to  note,  especially  for  this  audience  that: 

*  The  Gnosis  architecture  inherently  provides  a  base 
for  a  trusted  environment. 

However,  Tvmshare ' s  approach  to  achieve  the  trusted  system  object¬ 
ive  is  different  from  the  traditional  approach.  And  it  is  not 
clear  at  this  time  how  the  currently  accepted  trusted  system  model 
can  be  mapped  into  the  Gnosis  architecture. 


*  Norm  Hardy,  the  architect  of  Gnosis,  along  with  some 
Mitre  people  perceives  a  knowledge  gap  in  this  area. 

*  Norm  is  going  to  briefly  address  our  concerns  with 
the  mechanisms  and  approaches  of  the  secure  system 
evaluation  effort,  not  as  a  criticism  of  the  process, 
but  rather  as  a  search  for  a  broader  set  of  perspect¬ 
ives  . 

Thank  you  and  please  help  me  welcome  Norm  Hardy  to  the  podium. 
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TRUSTED  COMPUTER  SYSTEMS 


REIN  TURN 

THE  RAND  CORPORATION 

Since  June  1978  the  DoD  Computer  Security  Consortium  has  con¬ 
ducted  a  Computer  Security  Initiative  program,  with  the  goal  of 
achieving  widespread  availability  of  "trusted  ADP  systems"*  for  use 
within  the  Department  of  Defense  (DoD),  in  other  government  agen¬ 
cies,  and  in  the  private  sector.  For  the  government,  "widespread 
availability"  means  the  use  of  commercially  developed  trusted  sys¬ 
tems  whenever  possible.  Effective  January  1,  1931,  the  Director  of 
the  National  Security  Agency  (NSA)  was  assigned  responsibility  for 
the  evaluation  of  computer  security  for  the  DoD  and  thus  will  serve 
as  Executive  Agent  for  the  Computer  Security  Initiative.  One  of  nis 
functions  will  be  the  compilation  of  a  DoD  Evaluated  Products  List 
of  trusted  systems. 

To  date,  the  three  major  activities  of  the  initiative  have  been 
(1)  coordination  of  DoD  research  and  development  efforts  in  computer 
security,  (2)  identification  of  efficient  evaluation  procedures  for 
trusted  operating  systems  and  their  uses,  and  (3)  identification  of 
incentives  for  the  computer  industry  to  develop  trusted  systems  as 
part  of  its  standard  product  lines.  This  report  addresses  the  third 
task.  It  analyzes  the  needs  for  trusted  computer  systems  in  the 
civilian  agencies  of  the  federal  government,  in  state  and  local 
governments,  and  in  the  private  sector. 

Protection  is  needed  in  computer  systems  to  (1)  safeguard 
assets  '  r  resources,  (2)  comply  with  certain  laws  and  regulations, 
(3)  enforce  management  control,  and  (9)  assure  the  safety  and 
integrity  of  computer-controlled  processes  or  systems.  Additional 
incentives  for  implementing  trusted  systems  might  be  to  realize 
operational  economies,  to  achieve  marketing  advantages,  and  to 
enhance  an  organization's  public  image. 

Protection  of  programs  and  data  in  computer  systems  involves  a 
variety  of  physical,  personnel,  and  hardware/software  security  tech¬ 
niques;  administrative  and  operational  procedures;  and  computer- 
communication  security  techniques.  The  most  difficult  task  to  date 
has  been  the  development  of  trusted  operating  systems — a  necessity 


*A  "trusted"  ADP  (automated  data  processing)  system  is  one  that  em¬ 
ploys  sufficient  hardware  and  software  integrity  measures  to  allow 
its  use  for  simultaneous  processing  of  multiple  levels  of  classified 
and/or  sensitive  information.  See  the  Glossary  of  Technical  Terms 
in  Appendix  A  for  other  definitions. 


in  resource-sharing,  multiuser  systems  to  prevent  users  from 
interfering  with  each  other  and  to  control  access  to  sensitive  data 
files  or  processing  operations.  The  trusted  operating  systems 
sought  by  the  Computer  Security  Initiative  Program  have  a  nigh 
potential  for  providing  a  solution  to  many  of  these  problems. 

In  general,  the  use  of  current  computer  security  techniques 
entails  some  reduction  of  system  throughput,  as  well  as  some  modifi¬ 
cation  of  existing  application  software  or  data  bases.  Some  poten¬ 
tial  users  of  trusted  systems  are  concerned  about  these  impacts  on 
their  existing  computer  applications.  However,  there  is  a  clear 
trend  in  computer  hardware  architectures  and  in  software  development 
toward  including  features  that  would  be  very  useful  for  implementing 
performance-effective  trusted  systems;  thus,  performance  loss  is 
likely  to  be  far  less  of  a  problem  in  the  future.  Conversion 
requirements  for  application  software  can  also  be  reduced  by  design¬ 
ing  trusted  systems  to  be  compatible  witn  existing  operating  systems 
(as  has  been  done,  for  example,  in  the  KVM  and  KSOS  efforts).  A 
data-base  conversion  may  be  necessary  (e.g.,  to  include 
sensitivity-level  information) ,  but  this  is  usually  a  one-time 
effort. 

Computer  security  is  needed  in  the  civilian  agencies  of  the 
federal  government  primarily  for  3sset  and  resource  protection  and 
for  regulatory  compliance.  Many  agencies  are  responsible  for  finan¬ 
cial  disbursements  or  collections  and  thus  are  subject  to  attempts 
to  perform  unauthorized  transactions.  Trusted  systems  with 
appropriate  operational  and  administrative  controls  can  protect 
against  unauthorized  actions,  unless  these  actions  are  performed  by 
malicious  or  untrustworthy  authorized  users.  Here,  additional  con¬ 
trols  must  be  designed  into  the  application  programs. 

AIL  civilian  agencies  of  the  federal  government  are  subject  to 
the  requirements  for  data  security  and  integrity  of  Transmittal 
Memorandum  # 1  of  Office  of  Management  and  Budget  Circular  A— 7 1 • 
Personal  information  on  individual  citizens  that  is  maintained  by 
these  agencies  is  also  subject  to  the  confidentiality  requirements 
of  the  Privacy  Act  of  1974.  Trusted  operating  systems  can  provide  a 
tool  for  effectively  meeting  these  requirements. 

Protection  needs  in  state  and  local  government  computer  systems 
are  similar  to  those  in  federal  government  systems,  although  they 
are  on  a  smaller  scale  and  there  is  considerable  variation  from 
state  to  state.  Financial  disbursements  and  collections  account  for 
a  large  part  of  state  and  local  governments'  computer  use,  but  regu¬ 
latory  requirements  for  security  are  less  stringent;  indeed,  many 
states  have  not  enacted  fair  information  practices  U-ws,  and  some  do 
not  have  laws  requiring  confidentiality  of  computerized  criminal- 
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history  or  public  health  information.  Although  these  state  agencies 
may  have  less  compelling  needs  for  trusted  systems  and  they  may  be 
more  constrained  by  economic  considerations,  trusted  operating  sys¬ 
tems  can  greatly  enhance  the  controllability  and  auditability  of 
state  and  local  government  computer  systems,  and  as  a  consequence, 
they  would  increase  public  trust  in  government  operations. 

In  the  private  sector,  business  information  that  is  stored  and 
processed  in  nearly  all  corporate  computer  systems  is,  or 
represents,  a  valuable  asset  that  must  be  protected.  The  need  for 
effective  management  control  over  all  operations,  particularly  those 
that  involve  computers,  is  self-evlden' .  Strong  accountability 
requirements  have  been  established  by  the  Foreign  Corrupt  Practices 
Act  of  1977,  and  requirements  for  ensuring  confidentiality  of  per¬ 
sonal  employment,  medical,  and  financial  information  are  included  in 
state  laws.  In  addition,  federal  privacy  protection  requirements 
are  pending  that  will  affect  insurance,  health  care,  and  financial 
industries  in  the  private  sector.  Thus  there  is  a  strong  rationale 
for  protection  of  data  and  programs  in  private-sector  computer  sys¬ 
tems.  Trusted  operating  systems  could  provide  that  protection,  as 
well  as  certain  collateral  benefits  in  the  areas  of  safety  and 
integrity,  marketing,  and  public  relations. 

The  widespread  availability  of  effective  and  economical  trusted 
operating  systems  is  predicated  on  computer  system  vendors'  percep¬ 
tions  of  an  adequate  market  for  these  systems.  The  government  alone 
cannot  provide  enough  user  demand  to  be  attractive;  the  market  must 
also  include  the  private  sector.  Thus,  the  situation  is  somewhat 
circular:  A  market  will  develop  along  with  availability,  but  avai¬ 
lability  is  influenced  by  the  size  of  the  market.  The  trusted  sys¬ 
tem  technology  has  been  developed  and  is  not  being  demonstrated  by 
the  Computer  Security  Initiative,  so  the  technical  risk  to  vendors 
appears  relatively  small.  However,  the  preceived  need  to  maintain 
compatibility  between  trusted  systems  that  use  new  architectural  and 
design  concepts  and  the  existing  equipment  and  software  bases  causes 
vendors  to  be  cautious  about  undertaking  such  development  efforts. 

Given  the  trend  in  new  operating  systems  and  software  packages 
toward  inclusion  of  stronger  controllability  and  auditability 
features,  it  appears  that  development  may  evolve  naturally  toward 
trusted  operating  systems.  A  demonstration  of  a  credible  rationale 
for  acquisition  and  implementation  of  trusted  systems,  as  attempted 
in  this  report,  may  provide  the  additional  increment  of  incentive 
for  vendors  to  submit  their  systems  for  evaluation  and  inclusion  in 
the  Computer  Security  Initiative's  Evaluated  Products  Lists. 

Trusted  systems  can  contribute  effectively  to  the  solution  of 
the  growing  problems  of  protection  of  assets  and  resources, 
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compliance  with  laws  and  regulations,  assurance  of  safety  and 
integrity,  and  implementation  of  full  management  control.  In  addi¬ 
tion,  trusted  systems  may  provide  operational  economies,  marketing 
advantages,  and  public-image  enhancement.  They  are  needed  in  a 
variety  of  applications  that  constitute  a  market  that  should  be  of 
considerable  interest  to  vendors  and  that  should  strongly  encourage 
participation  in  trusted  system  development  efforts.  Their  use 
could  serve  the  interests  of  private  business  and  industry,  as  well 
as  public  policy,  public  safety,  and  national  welfare. 
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POTENTIAL  OPERATIONAL  ECONOMY 


•  Realization  depends  on  context  and  situation 

•  Elimination  of  "  make  shift''  security  procedures 

•  Reduced  duplication,  personnel  clearances. 

downtime  losses 

•  Reduced  insurance  premiums 
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OTHER  CONSIDERATIONS 

•  Cost  effectiveness  of  trusted  systems 

•  Impacts  on  performance 

•  Interoperability  and  compatibility 

•  Security  policy  versatility 
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TRUSTED  SYSTEM  COST-EFFECTIVENESS 

•  Performance  losses  will  be  reduced 

Use  of  hardware  features 

New  architectures  support  trusted  systems 

lessons  learned  are  being  applied 

•  Software  conversion  can  be  minimized 

Compatibility  will  be  a  design  goal 

•  Oata  base  conversion  may  be  required 
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TRUSTED  SYSTEM  NEEDS: 
FEDERAL  CIVILIAN  AGENCIES  -  1 


•  Protection  of  assets  and  resources 

Massive  financial  disbursements  or 
collections 
Vulnerable  to  fraud 

Trusted  systems  improve  access  control, 
audit  trails 

•  Management  control 

•  Safety  and  integrity 

•  Operational  economy 
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TRUSTED  SYSTEM  NEEDS: 
FEDERAL  CIVILIAN  AGENCIES  -  2 

•  Regulatory  compliance 

Transmittal  Memo  «1  OMB  Circular  A  71 

Physical  technical,  administrative  safeguards  required 

GSA  regulations 

FPMR  101  35  3 
FPMR  101  36  7 
F  PR  1  4  1107  21 

Privacy  Act  of  1974 

Federal  Personnel  Manual.  Ch  293  29  7 
Freedom  of  Information  Act 

Rand 


TRUSTED  SYSTEM  NEEDS: 
FEDERAL  CIVILIAN  AGENCIES  -  3 

•  Other  considerations 

Funding  of  security  requirements 

Enforcement 

Mission  oriented  agencies 

Cost  effectiveness  of  security  mechanisms 

Physical  and  administrative  security 
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TRUSTED  SYSTEM  NEEDS: 

STATE  AND  LOCAL  GOVERNMENTS  -  1 


•  Protection  of  assets  and  resources 

•  Regulatory  compliance 

Information  confidentiality  statutes 
Fair  information  practices  laws 
Criminal  justice  systems 
Pending  federal  legislation  regarding  social 
services 

•  Management  control 
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STATE  AND  LOCAL  GOVERNMENTS  -  2 


•  Safety  and  integrity 

•  Operational  economy 

•  Other  considerations 

Cost  is  important 
Consolidated  systems 
Public  perceptions 


TRUSTED  SYSTEM  NEEDS: 
PRIVATE  SECTOR  -  1 


•  Rationale 

Computers  are  a  necessity 

Concern  with  interruption  and  consequences 

Trusted  systems  needed 

Cost  ar.d  risk  tradeoffs  important 

•  Protection  of  assets  and  resources 

Business  records,  accountings  of  assets  and  receivables 
Planning,  marketing,  manufacturing 
Computer  related  crime  and  fraud 
Disgruntled  employees 
Grass  roots'  growth  of  threats 


TRUSTED  SYSTEM  NEEDS: 
PRIVATE  SECTOR  -  2 


•  Regulatory  compliance 

Fair  Credit  Reporting  Act  of  1969 
Family  Educational  Rights  and  Privacy  Act  of  1974 
Financial  Privacy  Act  of  1980 
Pending  federal  laws 

H  R  1059  Privacy  of  medical  information 
HR  1061  Privacy  of  public  assistance  records 
Amendments  to  Fair  Credit  Reporting  Act 
State  laws  on  personnel  records 
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TRUSTED  SYSTEM  NEEDS: 
PRIVATE  SECTOR  -  3 


•  Regulatory  compliance 

Foreign  Cor.  jpt  Practices  Act  of  1977 
Accurate  record  keeping 
Management  control  over  access 
Accountability  established 
International  Data  Protection 

National  laws  Austria,  Canada.  Denmark.  France 
Germany,  Israel.  Luxembourg.  Norway,  and 
Sweden 

OECD  guidelines 

Council  of  Europe  convention 

•  Management  control 

•  Safety  and  integrity 

Real  time  systems 

Computer  aided  design  and  mod.  ling 


TRUSTED  SYSTEM  NEEDS: 
PRIVATE  SECTOR  -  4 


•  Operational  economies 

Reduced  personnel  security  costs 
Enhanced  auditability 

Reduced  security  enforcement,  training  costs 
Savings  on  insurance,  bonding 

•  Marketing  advantages 

Security  assurance  to  clients 

Demonstration  of  concern  about  confidentiality  and  privacy 
Reduction  of  victimization  potential 
Enhanced  public  image 

•  Other  considerations 

Cost  effectiveness 
Risk  tradeoffs 
Management  support 


CONCLUDING  REMARKS 


•  Need  exists  for  trusted  computer  systems 

•  Incentives  are  there  for  trusted  system  use 

•  Potential  market  is  growing 

•  Incentives  exist  for  vendors  to  produce  trusted 

systems 

•  Implementation  and  operational  questions  can  1  v 

resolved  satisfactorily 
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THE  SDC  COMMUNICATIONS  KERNEL 


The  SDC  communications  Kernel  is  intended  to. support  secure 
communications  applications,  such  as  secure  front  ends  and 
terminal  access  systems.  It  is  a  minimal  operating  system, 
capability-based,  and  nas  a  basic  structure  tnat  we  nope 
will  ease  the  problem  j£  formal  specification  and 
verification.  [1] 

The  Kernel  is  oriented  towards  support  of  communications 
systems  in  tnat  it  offers  extensive  facilities  for 
interprocess  communications,  because  of  its  restricted  aim, 
it  does  not  support  dynamic  cnanges,  such  as  creation  of 
processes . 

The  SDC  communications  Kernel  nas  been  operational  for  a 
number  of  years  in  an  ARPANET-li^e  DoD  system,  we  feel  tnat 
the  capaoillties  and  speed  of  the  Kernel  are  well-adapted  to 
such  a  system,  and  are  competitive  with  other  systems  not 
using  a  Kernelized  architecture. 

The  Kernel  was  developed  under  the  primary  direction  of  Dr. 
Richard  wandell.  The  design  ana  coding  were  done  oy  Karl 
Auerbach,  David  Clemans,  and  Jay  Eaglstun. 


l.o  la  Heaeral 

The  SDC  communications  Kernel  is  a  descendant  of  the  UCLA 
Data-Secure  Unix  121  operating  system.  The  SDC 
communications  Kernel  remains  slmiliar  to  the  UCLA  Kernel  in 
the  following  major  areas: 

a.  The  SDC  kernel  is  a  minimalized  operating  system. 
It  is  a  small  amount  of  code  which  exists  to 
provide  environment  and  services  to  processes.  The 
processes  mav  De  regarded  as  "application"  code; 
there  is  no  partitioning  of  tne  Kernel  itself  into 
processes.  The  kernei  is  the  only  code  in  the 
machine  which  accesses  hardware  features  of  the 
machine  such  as  memory  protection  registers,  device 
registers,  etc.  In  a  PDP  li/70,  the  Kernel 


[11  Tne  question  of  verification  is  discussed  at 
the  end  of  section  2. 

12]  "Unix"  is  a  trademark  of  Bell  Laboratories. 
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consists  of  exactly  that  code  which  runs  in 
hardware  "kernel"  mode,  the  orivileqed  mode  of  the 
machine.  processes  run  in  non-tcernei  hardware 
mode . 

o.  The  SDC  communications  Kernel  is  intended  to  Pe  a 
verifiable  operating  system.  That  is,  it  should  be 
possible  to  formally  state  tne  services  and 
protections  that  it  supplies  and  to  formally  prove 
that  it  does  what  it  is  intended  to  do  and  no  more. 

c.  It  is  generally  felt  that  operating  system  code 
which  is  inter ruptable  is  very  hard  to  verify. 
Therefore  it  is  preferrable  for  a  verifiable 
operating  system  to  run  with  interrupts  completely 
locked  out.  This  is  the  policy  in  the  case  of  the 
SDC  communications  kernel. 

d.  Tne  SDC  communications  kernel  is  a  capability-based 
operating  system.  That  Is,  it  keeps  trac*  of 
processes*  allowed  accesses  to  various  opjects  by 
maintaining  for  each  process  an  array  of  data 
structures  called  capabilities,  each  of  which 
describes  an  object  and  an  allowed  access  to  that 
od ject . 

e.  The  kernel  is  entered  for  one  of  two  reasons; 

An  interrupt  is  received  from  a  device.  This 
can  only  occur  while  a  process  is  running,  ur 

A  kernel  call  (request  for  some  kernel  action) 
is  made  oy  some  process. 

In  either  case,  the  kernel  code  is  entered  via  a 
trap  or  interrupt  while  a  process  is  runninq,  runs 
straight  through  without  interruption  and  then 
exits.  The  kernel  exits  by  causing  tne  resumption 
of  the  execution  of  the  code  of  some  process  (which 
may  or  may  not  be  the  process  which  was  runninq 
when  the  kernel  was  entered). 

On  the  other  hand,  the  SDC  communications  kernel  has  been 
modified  so  as  to  be  appropriate  for  a  communications 
environment  rather  than  for  a  general  user-support 
environment.  For  this  and  other  reasons,  the  SDC 
communications  kernel  differs  from  the  UCLA  kernel  in  a 
number  of  important  ways; 

a.  l'he  SDC  communications  kernel  does  not  provide  for 
the  dynamic  creation  or  destruction  of  processes. 
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All  processes  exist  from  tie  time  that  the  CPU  is 
hooted  until  it  is  halted. 

р.  The  SDC  communications  kernel  does  not  provide  for 
swappinq  of  processes  In  and  out  of  memory.  All 
processes  are  permanently  resident  in  memory. 

с.  The  UCLA  system  runs  on  a  CPU  (11/70,  11/45,  etc) 

with  three  nardware  mooes:  kernel,  supervisor  and 
user.  The  kernel  runs  in  kernel  mode,  while  the 
supervisor  mode  contains  code  called  the  "unix 
emulator"  which  provides  an  environment  very  like 
that  of  standard  Unix  to  "applicat  ion"  code  runninq 
in  user  mode.  In  distinction,  "appl ication"  code 
written  for  the  SDC  system  runs  in  supervisor  mode 
and  makes  kernel  calls  directly.  (User  mode  Is 
unused.)  SDC  software  thus  can  run  in  CPUs  witn 
only  two  hardware  modes  (11/34  and  11/23).  (This 
is  perhaps  more  a  difference  in  usaqe  than  in  the 
kernels  themselves.  The  SDC  communications  kernel 
on  an  11/70  or  11/45  could  support  some  sort  of 
emulator  in  supervisor  mode,  which  could  in  turn 
provide  some  sort  of  standard  environment  to  code 
in  user  mode.) 

d.  The  SDC  communications  kernel  incorporates  very 

extensive  provisions  for  interprocess 

communications . 

e.  In  the  UCLA  system,  a  "Scheduler"  process  is 
responsible  for  choosinq  the  next  process  to  run. 
In  the  SDC  kernel,  processes  are  not  swapped  out, 
so  schedulinq  is  much  simplified  and  has  been  made 
part  ot  the  kernel. 

f.  In  the  UCLA  system,  a  "File  Manager"  process  is 
responsible  tor  givinq  capabilities  to  processes. 
In  the  SDC  system,  most  capabilities  of  processes 
(for  instance,  the  capability  to  access  a  certain 
peripheral)  are  assigned  statically  at  the  time  the 
system  Is  configured,  by  a  program  called  the 
"Super  linker" ,  running  under  normal  Unix.  The 
Superlinker  assembles  the  CPU  memory  Image  and 
gives  static  capabilities  to  processes  as 
Instructed  by  the  "superlinker  control  file",  which 
is  prepared  by  a  human  being.  It  is  this  human 
beinq  who  is  ultimately  responsible  for  deciding 
what  processes  are  allowed  to  communicate,  etc. 
(Some  capabilltes  are  given  to  and  taken  away  from 
a  process  dynamically  as  part  of  the  interprocess 
communication  facilities;  this  is  discussed  In  more 
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detail  below.)  A  separate  File  Manaaer  process  is 
not  used. 

The  SDC  communications  kernel  Is  written  In  a  version  of 
Pascal,  augmented  to  provide  certain  extensions  necessary 
tor  the  use  ot  Pascal  in  an  operating  system.  The  UCLA 
Pascal-C  translator  translates  this  into  C,  which  Is  then 
compiled  normally.  The  code  is  written  in  a  top-down, 
highly  modular  and  methodical  metnod,  wnlch  is  intended  to 
facilitate  verification,  altnougn  no  verification  or  formal 
specification  has  been  done  as  yet. 


2 .  o  SEcmrlxy.  Balicy  ...  4a  Exhale 

The  SDC  kernel  does  not  itself  implement  a  security  policy. 
In  a  typical  communications  system  usinq  the  kernel,  the 
total  security  policy  would  De  a  result  of  the  properties  of 
various  parts  of  the  system,  of  which  the  kernel  is  only  one 
part.  The  kernel  by  itself  does  not  auarantee  that  tne 
security  policy  is  correctly  implemented.  The  kernel  is 
only  responsible  for  maintaining  and  separatina  process 
environments,  and  providing  and  regulating  interprocess 
communications.  Thus,  the  properties  of  the  kernel  are 
related  to  the  total  security  rollcy  as  a  lemma  is  to  a 
theorem . 

An  example  may  help  to  make  this  clear. 

Consider  a  CPU  which  is  to  act  as  a  sort  of  terminal 
concentrator.  The  CPU  is  to  support  two  terminals,  one  of 
which  is  to  carry  unclassified  traffic  only,  and  the  other 
of  which  is  to  carry  classified  traffic  only.  The  TCP  and 
TELNET  protocols  are  to  be  used  to  provide  services  to  each 
of  these  terminals.  In  order  to  provide  separation  between 
the  classified  and  unclassified  traffic,  the  TCP  and  TELNET 
processes  are  duplicated.  The  internal  situation  in  the  CPU 
can  be  pictured  as  followed: 
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In  tnls  figure,  the  "drivers"  are  collections  of 
subroutines;  they  are  within  the  kernel,  since  they  must 
manipulate  the  pnysical  device  registers. 

The  Security  miix/demux  process  is  a  process  whose 
responsibility  it  is  to  separate  classified  and  unclassified 
traffic  streams  (on  reception)  and  to  me roe  tne  streams  on 
transmission.  we  do  not  speculate  here  on  what  basis  this 
is  done.  Hut  it  is  clear  tnat  this  process  is  performing  a 
highly  secur ity-relevant  function.  Therefore,  the  code  of 
this  process  must  be  appropriately  verified.  However,  it  is 
important  to  point  out  that  the  verification  of  the 
functioning  of  this  process  is  quite  distinct  from  the 
verification  of  the  kernel.  The  process  is  not  part  of  the 
kernel . 

The  TELNET  and  TCP  processes  are  likewise  processes,  not 
part  of  the  kernel,  because  of  the  scheme  diagrammed  aoove, 
we  can  nope  to  be  able  to  show  tnat  tne  malfunctioning  of 
any  of  these  processes  would  not  be  able  to  violate  security 
constraints.  (Note  that  this  diagram  represents  only  one 
example  of  a  system  which  might  be  build  on  the  kernel.) 

Note  tnat  tne  drivers  handle  unseparated  data;  therefore 
they  too  would  need  to  be  verified.  However,  this  is  true 
even  before  we  make  the  observation  that  they  handle 
unseparated  data:  They  must  be  verified  because  they  are 
part  of  the  kernel,  and  all  of  the  kernel  must  be  verified. 

Now  we  are  in  a  position  to  discuss  the  role  of  the  kernel 
Itself.  what  are  the  services  and  protections  that  the 
kernel  provides? 

First  of  ali,  the  kernel  provides  and  separates  the 
environments  of  the  processes.  For  example,  the  kernel  sets 
the  machine  mapping  registers  when  one  process  runs  so  that 
the  code  and  data  of  tnat  process  are  accessed,  and  so  that 
the  code  and  data  of  some  other  process  are  oat  accessed. 

Second  of  all,  the  kernel  provides  interprocess 
communications  facilities  as  specified  when  the  system  is 
configured.  In  the  figure  above,  for  example,  the  various 
arrows  represent  Interprocess  communications  mechanisms 
called  "queues".  (These  will  be  discussed  in  more  detail 
below. ) 

when  the  system  was  configured,  the  responsible  person 
specifies  what  processes  are  to  exist,  and  what 
communications  paths  between  them  are  to  exist. 

The  tool  by  which  this  is  done  is  the  "super  1  inker " 
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mentioned  aoove.  The  responsible  person  prepares  a 
"superilnker  control  tile",  f-or  instance,  tor  the  system 
pictured  aoove ,  tne  superlinxer  control  file  will  specify 
that  there  are  to  ne  five  processes.  f-.ach  of  these 
processes  has  previously  oeen  compiled,  ana  its  opject  coae 
is  ready  and  waiting.  The  control  tile  specifies  where  this 
ooject  code  is  to  ne  found,  furthermore,  the  control  file 
specifies  exactly  what  queues  are  to  exist  in  the  system, 
wnat  processes  are  ailowed  to  place  inf ormat ion  on  a  given 
queue,  and  wnat  processes  are  to  oe  allowed  to  take 
information  off  of  a  aiven  aueue. 

This  superlinker  control  file  Is  processed  ny  the 
superilnker  proaram,  which  is  running  under  whatever 
development  system  is  in  use.  (Hot  under  the  kernel.)  The 
superlinicer  prepares  the  complete  memory  image  o t  the  CP<J. 
In  particular,  it  prepares  the  kernel  tables  which  establish 
the  existence  of  the  various  gueues  and  what  processes  are 
allowed  to  enqueue  to  and  dequeue  from  earn  one  of  them. 
IThis  will  be  discussed  in  more  detail  oelow.) 

Now  we  can  describe  what  It  is  that  the  kernel  is  trusted  to 
do:  the  kernel  Is  trusted  to  correctly  implement  and 
administer  the  system  described  by  the  superlinker  control 
file.  For  example,  if  the  superilnker  control  file 
describes  the  systemi  shown  in  tne  fiaure  above,  then 
verification  of  the  kernel  will  ensure  that  the  unclassified 
TELNET  process  will  not  be  able  to  dequeue  information  from 
the  queue  which  is  shown  as  leading  from  the  classified  TCP 
to  the  classified  TELNET. 

in  order  to  correctly  understand  the  nature  of  the  security 
policy  of  the  kernel  as  shown  in  tne  example  above,  it  is 
very  important  to  understand:  The  MUX/HEMUX  process  may  be 
described  as  "trusted"  in  that  it  is  trusted  by  the  human 
beings  who  design,  configure  and  use  tne  system.  However, 
it  is  inappropriate  to  describee  this  process  as  "trusted" 
by  the  kernel.  The  kernel  does  not  nave  a  notion  of 
"trusted"  process.  In  particular,  there  Is  no  "trusted" 
Doolean  in  the  per-process  table  maintained  by  the  kernel. 
The  kernel  knows  only  what  communications  paths  each  process 
has  been  authorized  to  use. 

In  the  example,  the  queue  from  the  net  driver  to  the 
MUX/DEMUX  process  carries  both  classified  and  unclassified 
information,  while  the  queue  from  the  unclassified  TCP  to 
the  unclassified  TELNET  carries  only  unclassified 
information.  Thus,  from  a  security  point  of  view,  these 
queues  are  very  different.  However,  there  Is  nothing  in  tne 
kernel  corresponding  to  this  difference  in  tne  nature  of 
these  queues. 
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>*e  can  describe  the  philosophy  here  as  this:  the  "real" 
security  policy  is  executed  by  the  person  who  prepares  the 
superlinker  control  tile.  The  kernel  is  responsible  only 
tor  seeing  that  that  person's  desclsions  are  enforced.  Note 
that  this  is  appropriate  for  the  purpose  for  which  the  SDC 
kernel  has  oeen  designed.  That  is,  since  the  system  is 
static,  there  is  no  need  to  burden  the  kernel  with  code, 
algorithms,  etc,  tor  making  security-related  desclsions. 
Instead,  these  desclsions  are  made  Deforehand,  and  the 
kernel  is  only  responsible  for  enforcing  them. 

Note  that  in  the  example,  the  Line  Driver  software  in  the 
kernel  handles  Doth  terminals.  There  is  no  reason  to 
provide  two  copies  of  this  software;  both  copies  would  nave 
to  reside  in  the  kernel,  so  as  to  access  the  hardware  device 
registers,  and  would  have  be  verified  to  function  properly, 
as  is  true  for  any  part  of  the  kernel  and  the  kernel  as  a 
whole.  There  would  be  no  hardware  separation  between  the 
two  copies. 

Note  that  as  part  of  its  functioning,  the  driver  must  take 
data  from  the  queue  from  the  unriasaii < ed  TELNET  process, 
and  place  it  on  the  line  to  the  uacia&siilfid  terminal. 
Similarly  for  the  classified  terminal  and  for  the  otner 
direction  of  flow,  it  must  be  verified  that  this  function 
is  performed  correctly;  but  this  is  covered  by  the 
reauirement  that  all  the  kernel  functioning  must  be  verified 
to  perform  correctly. 


If  the  kernel  were  to  be  verified,  what  is  it  that  would  be 
verified?  what  would  oe  the  formal  properties  that  would 
have  to  be  verified  to  hold? 

The  kernel  is  responsible  for 

a.  Maintaining  and  separating  process  environments. 

b.  Providing  and  regulating  interprocess 

communications . 

c.  Operating  devices. 

Verification  of  the  kernel  would  require  formally  stating 
the  nature  of  these  responslbiiites.  (These  statements 
would  probably  Include  formal  statements  of  the  effects  of 
the  various  kernel  calls.)  Then  it  would  be  necessary  to 
formally  prove  that  the  kernel  code  does  properly  carry  out 
these  responslblites. 

As  already  emphasized,  verification  of  the  kernel  would  be 
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only  part  of  what  would  have  to  be  done  to  verify  that  a 
given  system  satisfies  some  security  nollcy.  various  non- 
kernel  parts  of  the  system,  as  well  as  various  aspects  of 
the  total  system  architecture ,  would  also  have  to  ne 
verified. 

Certain  parts  of  the  support  software  used  to  produce  the 
system  would  also  have  to  be  appropriately  verified. 
Clearly,  an  important  part  of  tnis  software  is  the 
superlinker .  The  output  of  the  sunerlinker  is  source  code 
versions  of  the  Kernel  tables,  which  are  then  compileo, 
linked,  and  oullt  Into  a  total  memory  image.  These  Kernel 
tables  could  be  human-inspected,  but  this  would  be  a  very 
difficult  task,  which  itself  woula  use  many  machine  aids. 
It  there  were  any  chance  of  having  to  do  this  tedious  human 
inspection  repeatedly,  verification  of  the  superlinker  would 
be  the  proper  thing  to  do  instead. 

The  kernel  was  developed  in  a  context  *hicn  emphasized  the 
production  of  working  code  in  a  relatively  short  time.  Kor 
this  reason,  it  was  decided  neither  to  formally  specify  the 
properties  of  the  kernel,  nor  to  attempt  to  formally 
demonstrate  anythina  about  It.  Sorre  such  effort  may  De  made 
in  the  future. 

It  is  of  course  the  case  that  code  which  was  not  developed 
from  formal  spec! f i cat  ions  may  be  quite  difficult  to 
formally  verify  after  the  fact,  and  will  almost  certainly 
have  to  be  modified  in  order  to  be  verified.  This  mav  be 
true  because  actual  security  flaws  are  found  by  the  formal 
analysis,  or  because  some  aspects  of  the  existing  code  are 
particularly  unamenable  to  verification.  However,  there  are 
some  aspects  of  the  existina  kernel  -  the  capability 
orientation  In  particular  -  which  we  hope  will  ease  formal 
verification . 


3.0  XLe  EPitlxaoaent  at  a  Eeq cess 


To  begin  with,  we  emphasize  that  a  "process"  is  not  part  oi 
the  kernel,  but  rather  an  "application"  oroaram  for  which 
the  kernel  provides  environment  and  services.  No  part  of 
the  kernel  is  described  as  a  process. 

In  a  POP  11/34,  the  virtual  address  space  of  a  process 
comprises  64K  bytes  -  each  process  produces  16-nlt  addresses 
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as  It  accesses  memory.  Tnese  virtual  addresses  are 
translated  to  physical  addresses  by  the  memory  management 
hardware.  This  hardware  manages  the  process'  virtual  memory 
space  in  eight  pieces,  each  of  wnich  contains  8K  bytes. 
These  pieces  are  the  "pages”  of  a  process*  virtual  address 
space . 

These  pages  are  used  as  follows: 

a.  One  page  accesses  the  "library".  This  is  a 
collection  of  commonly  useful  subroutines.  A 
typical  routine  would  be  a  routine  for  converting 
between  a  macnine  clock,  wnich  might  read  in 
seconds  past  January  1,  1970,  to  human  time  (date 
and  time).  The  Horary  is  read-only  to  all 
processes . 

b.  One  or  more  pages  are  used  to  access  the  orocess’ 
text  ...  that  is,  its  executaole  code.  This  access 
is  read-only. 

c.  One  or  more  pages  are  used  to  access  the  process' 
data  area  ...  that  is,  the  area  in  which 
initialized  variables  are  Kept.  This  area  is 
normally  read-only,  but  may  oe  made  writeable,  by 
special  Instructions  to  the  superlinker. 

d.  One  or  more  pages  are  used  to  access  the  process' 
so-called  "bss"  area  ...  that  is,  the  area  in  whicn 
variables  which  are  initially *zero  are  kept.  This 
area  Is  read-wrlte. 

e.  The  last  page  (page  seven)  accesses  the  process' 
"communications  olock".  This  Is  an  area  of  memory 
snared  by  the  process  and  tne  kernel  and  used  for 
communications  between  a  process  and  the  kernel. 

f.  The  remaining  pages  (there  are  at  most  three)  are 
free  to  be  used  to  "map  in"  blocks  of  data  passed 
from  process  to  process  using  the  interprocess 
communications  mechanisms  described  below.  These 
are  referred  to  as  mappable  cages. 

In  an  11/70,  the  situation  is  slmillar,  except  that  an  11/70 
has  "separate  I  and  D  space",  and  so  has  twice  as  many  pages 
for  each  process  as  the  11/34. 

When  an  event  occurs  which  affects  a  process,  the  kernel 
posts  a  notification  of  the  event  in  the  process' 
communications  block,  which  the  process  looks  at  in  the 
course  of  its  main  loop,  which  is  described  below.  (Section 


The  SDC  Comrauni cations  Kernel 


August  1 9 n i 


4  discusses  traps  and  Interruptions  in  more  detail.) 

In  tne  SDC  system,  programmers  write  code  which  makes  kernel 
calls  directly.  There  is  no  "emulator"  to  provide  tne 
running  process  with  an  environment  like  tnat  of  some 
familiar  operating  system.  (inis  is  in  distinction  to  the 
UCLA  Data  Secure  UMX  system.)  since  tne  programmer  is 
writing  code  to  run  in  an  environment  which  is  unfamiliar  to 
him,  we  nave  taken  the  approach  of  providina  a  standard 
top-level  structure  for  every  process.  (This  also  makes 
understanding  a  process  written  t>y  another  programmer 
considerably  easier.) 

This  standard  top-level  structure  is  implemented  by 
providing  each  programmer  with  tne  same  "main"  routine. 
(Again:  we  emphasize  tnat  this  "main"  is  part  of  the 
process,  not  part  of  the  kernel.)  The  entire  code  of  a 
process  consists  of  subprocedures  called  from  this  highest 
level  procedure  "main".  (In  particular,  there  are  no 
"Interrupt  handler"  or  "completion"  routines  wnicn  are 
initiated  directly  by  tne  kernel.)  The  outline  ot  main  is  as 
follows ; 

procedure  main; 
begin 

initialize; 
while  (true)  do 
begin 

Set  "summary"  flag  in  communications  block  to  false, 
while  (some  external  event  remains  unprocessed)  do 
pegin 

Call  procedure  to  process  that  external  event. 

end; 

k„SLEEP; 

end; 

end; 

The  procedure  "main"  is  caused  to  begin  executing  when  the 
system  is  Dooted.  Main  never  exits. 

Tne  process  begins  Dy  calling  an  initialization  subroutine, 
and  then  enters  an  Infinite  loop.  This  loop  basically  does 
nothing  except  process  external  events.  ("External"  here 
means  external  to  the  process.)  The  process  detects  that 
there  are  external  events  to  be  processed  by  examining  its 
communications  block.  When  there  are  no  external  events  to 
be  processed,  the  process  makes  the  system  call  k_sleep  to 
give  up  tne  CPU  until  some  external  event  occurs.  «men  an 
external  event  does  occur,  the  kernel  awakens  the  process, 
which  resumes  execution  just  as  though  the  K-SLEEP  call  had 
returned  immediately. 
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From  the  ordinary  programmer's  point  of  view,  writing  a 
process  to  run  under  the  sue  kernel  consists  in  codlnq 
various  procedures  whicn  are  called  from  main,  tne 
procedures  which  they  in  turn  call,  etc. 

Ihe  "summary"  flaq  in  the  communicat ions  block  is  used  in 
conjunction  witn  the  K_SLEEP  call  to  avoia  a  possible  race 
condition. 

(If  tne  summary  flaa  were  not  used,  the  following  might  be 
possible : 

A  process  has  processed  all  previously  pending  external 
events,  has  decided  that  there  is  nothing  more  to  do, 
but  has  not  yet  made  the  K_SLEt:p  call.  how  an  external 
event  occurs.  The  kernel  posts  a  notification  of  tne 
event  in  the  process'  communication  block.  However, 
the  process  has  already  decided  to  go  to  sleep.  Tne 
process  now  makes  tne  K_SLKfP  call.  As  far  as  tne 
kernel  can  see,  the  process  has  disposed  of  the  new 
event.  Inus  the  process  goes  to  sleep  without  handling 
the  event,  and  might  even  sleep  forever.) 

The  summary  flag  avolus  this  race  condition  as  follows:  Any 
time  that  the  kernel  posts  an  external  event  to  a  process. 
It  sets  the  summary  flaa  in  the  process'  communications 
block  to  "true".  If  the  summary  flag  is  true  when  tne 
F_SLEf£P  call  Is  made,  then  the  process  is  not  put  to  sleep; 
the  K_Sl,F.EP  call  returns  immediately.  It  is  easy  to  see 
that  this  mechanism,  and  its  usage  as  in  "main"  above, 
avoids  tne  race  condition. 


4.0  Xat.acxuat&  and  Xnans 


The  kernel  operates  with  all  interrupts  locked  out  (PDP-11 
priority  7).  Thus,  if  a  device  wishes  to  interrupt  while 
the  kernel  Is  executing,  the  Interrupt  win  remain  pending 
until  the  kernel  exits  and  a  process  starts  to  execute. 
Then  that  process  will  be  immediately  interrupted. 

Suppose  that  an  Interrupt  occurs  while  a  process  is 
executing.  The  CPU  will  pe  interrupted  and  the  kernel  will 
handle  the  interrupt.  When  the  process  resumes  executing, 
it  will  resume  <-t  exactly  the  place  at  which  it  was  when  the 
Interrupt  took  place.  In  this  sense,  the  interrupt  is 
transparent  to  the  process. 

If  the  interrupt  implies  that  some  process  should  be 
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notified  of  a  certain  external  event,  then  the  Kernel  posts 
a  notification  in  the  communications  block  of  tnat  process. 
The  process  is  awakened  if  it  was  previously  asleep.  If  the 
notified  process  happens  ^lso  to  be  the  process  that  was 
running  when  the  interrupt  tooK  place,  then  the  process 
finds  out  aoout  the  even^.  wn>n  it  returns  to  its  "main" 
routine  and  examines  its  communications  block. 

Thus  a  process  runs  without  interrupts  visible  to  that 
process.  The  only  possible  race  conditions  that  might 
affect  a  process  are  concerned  with  the  reception  of 
notiticat  ions  of  exte-rnal  events.  Tnese  problems  are 
handled  by  the  summary  flag  and  the  provision  of  a  standard 
"main".  Thus,  a  programmer  can  produce  code  for  a  process 
without  cons i aerations  of  race  conditions,  critical  areas, 
etc.  This  is  clearly  of  g*eat  benefit  in  a  security- 
oriented  system  which  is  also  production-oriented. 

The  only  traD  used  in  tne  system  is  the  so-called  "KMT" 
trap,  which  is  used  by  a  process  to  ma<e  a  Kernel  call.  The 
occurence  of  a  trap  while  in  Kernel  mode  would  indicate  a 
bug  in  the  kernel  code.  In  this  case  the  kernel  halts  the 
machine.  A  trap  other  than  the  EhT  trap  while  a  process  is 
running  indicates  a  Dug  in  the  code  of  the  process.  The 
kernel  handles  this  by  causing  the  process  to  be  re-entered 
and  restarted  at  a  low  virtual  process  address. 


5.0  ibe  Capas  .Lilly  List 

The  Kernel  maintains  for  each  process  a  "capability  list". 
This  is  an  array  of  records,  called  "capability  slots".  An 
index  into  tnis  array  is  called  a  "capability  index".  A 

capability  slot,  if  not  empty,  contains  a  "capabi 1 1 ty" .  A 
capabiiity  names  some  "object"  and  describes  an  allowed 

"access"  to  that  object.  Some  examples: 

a.  A  (statically  defined)  section  of  a  disk  is  an 

object.  heading  and  writing  are  the  two  important 
accesses . 

b.  The  central  clocK  maintained  by  the  Kernel  is  an 
ooject.  The  only  access  which  may  be  given  by  a 
capabiiity  to  the  clocK  is  the  ability  to  set  the 
clock.  (Any  process  is  allowed  to  read  the  clock 
without  having  an  explicit  capability  to  do  so.) 

c.  A  block  of  memory  is  an  object.  Reading  and 

writing  are  the  two  Important  accesses. 
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The  capability  'list  for  each  process  is  maintained  by  the 
Kernel.  Some  capabilities  are  placed  in  the  list  by  tne 
superlinKer  at  the  time  that  the  CPU  memory  image  is 
prepared,  while  other  capabilities  are  placed  in  or  removed 
from  the  list  in  response  to  Kernel  calls.  The  process  gets 
no  access  to  its  capability  list,  eitn.er  read  or  write. 

A  capability  serves  not  only  to  define  what  accesses  a 
process  nas  to  a  given  object;  it  serves  to  actually 
identify  that  object.  For  example,  suppose  tnat  one  process 
communicates  witn  another  process  via  a  "queue",  as 
discussed  further  below.  When  enqueueinq  information  to  the 
other  process,  the  process  names  tne  queue  by  giving  tne 
capability  index  to  the  capability  which  gives  tne  process' 
access  to  its  end  of  tne  queue. 

As  another  example,  suppose  that  a  certain  process  is  to  ne 
allowed  to  set  the  system  clocK.  The  superlinKer  control 
file  will  contain  lines  instructing  tne  superlinKer  to  set 
into  the  process'  capability  list  a  capability  to  set  tne 
clocK.  The  superlinKer  control  file,  in  the  part  describing 
tne  capabilities  which  the  process  is  to  have,  win  contain 
a  line  sucn  as 

clocK  capability  on  12 

This  specifies  that  the  process  is  to  have  a  capability  to 
set  the  system  clocK,  located  at  index  12  in  its  capability 
list,  when  the  process  maKes  the  K_SET_TIME  system  call, 
one  of  tne  parameters  will  be  the  number  12.  In  fact,  tne 
call  is 


K_SET_TIME (12,  new_time) 

when  this  call  is  made,  the  Kernel  will  enecK  slot  number  12 
of  the  process'  capability  list  to  see  if  it  contain  a 
capability  to  set  tne  clocK.  Since  it  does,  the  Kernel  will 
do  what  the  call  asKs  it  to  do,  namely  to  set  the  clocK. 
bote  that  the  Kernel  does  not  search  the  capability  list  of 
the  process  for  a  capability  allowing  the  process  to  do  what 
it  nas  asKed  to  do. 

If  the  process  by  mistaKe  made  the  call 
K.SET.T1MF C 1 3 ,new_tlme) ,  the  Kernel  will  looK  in  slot  number 
13  of  the  process'  capability  list.  Since  tnis  slot  does 
not  contain  a  capability  to  set  the  clocK,  the  call  will 
fail.  That  is,  the  Kernel  will  give  the  process  a  return 
indicating  that  the  call  failed  oecause  of  a  "bad 
capability"  -  that  Is,  the  capability  at  the  indicated 
capability  index  was  not  what  was  required.  Also,  the  clocK 
will  not  be  set. 
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Notice  tnat  altnough  the  process  cannot  either  read  or  write 
its  capability  list,  since  that  list  is  maintained  entirely 
by  the  kernel,  the  process  must  know  what  is  in  eac.o 
capaoility  slot.  Capabilities  are  piaceo  in  the  caoaDility 
list  of  a  process  eitner  statically  oy  tne  superlinker,  like 
the  capacility  to  set  the  clock,  or  else  as  a  result  of 
kernel  calls  made  by  tne  process,  as  in  the  case  of  getting 
a  data  clock  as  described  below,  'ihus  the  process  can  keep 
track  of  the  entries  or  its  capat-illty  list  without  in  fact 
being  able  to  read  it. 


p.O  laxexutacass  Cam,  on  leal  lags. 

This  section  describes  tne  major  method  or  interprocess 
communications  unaer  the  Sl'C  kernel,  namely  the  enaueieing 
and  dequeueing  of  clocks.  (mere  are  other  methods  of 
Interprocess  communications  which  are  not  described  here.) 

The  kernel  maintains  a  pool  of  tree  memory  blocks.  These 
are  blocks  of  12b  bytes  of  memory  (in  our  current 
implementations).  The  blocks  are  clear  as  kept  In  the  free 
pool.  when  one  process  wishes  to  send  a  message  to  another 
process,  tne  sequence  of  events  is  as  follows: 

a.  The  first  process  gets  a  clock,  and  writes 

information  in  it. 

d.  Tne  first  process  places  the  clock  on  a  nueue  to 
the  second  process. 

c.  Tne  secona  process  takes  the  block  off  the  queue 
and  reads  the  Information  from  it. 

a.  The  second  process  returns  tne  Mock  to  the  kernel, 
which  clears  it  and  , uts  it  pack  in  the  free  pool. 

In  more  detail,  the  steps  are  as  follows: 

The  first  process  makes  a  K_GET— DAT A_BDCiCK  kernel  call.  An 
argument  to  this  is  a  capability  index.  This  must  be  the 
index  to  a  currently  empty  capaDility  slot.  The  kernel  will 
remove  a  block  from  the  free  pool  and  place  a  read-write 
capability  to  the  block  in  the  specified  slot. 

The  process  then  makes  a  K_map  call.  This  specifies  the 
capability  index  where  the  capability  to  the  clock  is 
located,  and  one  of  the  orocess'  virtual  pages,  which  must 
be  unused.  The  kernel  in  response  sets  the  memory 
management  hardware  to  make  the  block  appear  at  the 


P-15 


The  SDC  Communications  Kernel 


August  19H1 


beginning  of  that  pane  of  the  process'  virtual  address 
space,  giving  tne  process  read  ?nd  write  access  to  the 
block.  This  is  called  "maoping  tre  dIock  in". 

The  process  can  now  read  and  write  the  block,  using 
references  to  a  data  structure  which  is  forced  to  reside  at 
tne  appropriate  location  in  the  process'  virtual  address 
space . 

No*,  tnls  sequence  or  operations  is  a  natural  pair:  when  a 
process  gets  a  data  clock,  it  win  almost  certainly  want  to 
"map  the  bloc*  in"  to  access  it.  Thus,  these  two  calls  can 
be  contDined  for  qreater  etficency.  This  is  in  fact  what  has 
been  done.  That  is,  the  K_GfcT_nATA  block  call  has 
additional  parameters  which  win  allow  the  calling  process 
to  map  tne  clock  in  as  part  of  the  call. 

The  process  then  makes  a  K.ENGlitUK  call.  The  parameters 
here  are  the  capability  index  naming  the  block,  and  tne 
capability  index  naming  the  enqueue  end  of  the  queue.  (The 
queue  is  defined,  and  the  capability  to  the  queue  is  given, 
by  tne  super  linker . )  In  response,  the  kernel  removes  the 
capability  to  the  block  from  the  first  process'  capaoility 
list,  puts  the  block  on  the  queue  (wnich  is  maintained 
entirely  by  tne  kernel),  and  unmaps  the  block,  so  that  tne 
process  no  longer  has  access  to  It.  It  posts  a  notification 
to  the  secona  process  that  the  queue  has  something  on  it, 
and  wakes  the  second  process  if  it  is  asleep. 

The  second  process  makes  a  K_DEQUEUE  call.  The  parameters 
here  are  a  capability  index  to  the  dequeue  end  of  the  queue, 
and  a  capability  index  to  an  unusea  slot  in  its  capability 
list.  The  kernel  removes  the  block  from  the  queue,  and  puts 
a  capability  to  that  block  in  the  specified  slot.  The 
normal  sequence  of  events  Is  that  a  receivlnq  process  win 
first  dequeue  a  block  and  then  map  it  In,  similiar  to  the 
situation  in  tne  case  of  the  K_GET_DATA_BLOCK  call. 
Therefore  the  K_DEyUEUE  call  has  optional  parameters  by 
which  the  calling  process  asks  tne  kernel  to  map  tne 
dequeued  block  in  to  a  specified  virtual  page. 

The  second  process  can  now  read  the  data  in  the  block. 

The  second  process  finally  makes  a  K„RELF ASE_DAT A_BLOCK 
kernel  call,  specifying  the  capability  index  at  which  the 
capability  referring  to  the  block  is  located.  The  kernel 
removes  the  capability#  unmaps  the  block  from  the  process' 
virtual  memory  space,  clears  the  block  and  returns  it  to  the 
free  pool. 

The  above  description  Is  one  of  the  simplest  of  the 
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Interprocess  communications  mechanisms  provided  hy  tne  SDC 
kernel,  one  of  tne  more  interesting  variations  Is  the 
anility  of  the  kernel  to  requlate  write-access  bv  a  process 
to  the  contents  of  a  block  on  a  basis  of  a  finer  aranularity 
than  tne  wnole  block  itself. 

This  facility  might  be  useful  if  there  were  a  process  that 
should  be  allowed  to  modify  certain  fields  in  a  block,  but 
not  other  fields.  It  might  be  the  case  that  some  process 
receives  a  block  from  another  via  a  queue,  and  should  be 
allowed  to  modify  a  "header"  field  within  the  block,  but  no 
other  part  of  the  clock. 

This  can  be  achieved  in  tne  SDC  Kernel  as  follows*  Special 
instructions  are  placed  in  the  superlinker  control  file. 
These  instructions  include  a  specification  (namely,  a  bit¬ 
mask)  of  which  bytes  of  the  bloc<s  dequeued  from  a  certain 
queue  tne  process  in  question  is  to  be  aole  to  alter.  The 
superlinker  then  contiqures  the  kernel's  tables  in  a  special 
way.  Now  when  the  process  dequeues  a  block  from  the  queue 
in  question,  the  process  gets  a  read-only  capability  to  the 
block.  when  the  process  uses  the  K_MAP  call  to  "map  the 
block  in",  the  kernel  sets  the  hardware  mappina  registers  so 
that  the  process  gets  only  read-access  to  the  block.  The 
process  sets  the  fields  it  is  permitted  to  set  by  maKlnq  a 
k^wkitE-BLuCK  call.  The  parameters  to  this  call  are  the 
capability  index  to  the  block,  alona  with  (the  address  of)  a 
buffer  of  128  bytes  in  the  process'  data  space.  The  kernel 
will  then  copy  from  that  buffer  to  the  block  those  bytes 
which  are  indicated  by  the  bit-mask  supplied  to  the 
superlinker  oy  the  superlinker  control  file. 

This  kind  of  f lne-granular ity  control  must  be  implemented  by 
the  kernel  software,  since  the  11/70  memory  nanagement 
hardware  does  not  have  the  necessary  capabilities. 


7.0  lime 

The  kernel  maintains  a  48-bit  "fast"  clock  which  is 
Incremented  every  10  microseconds,  usina  the  dec  kwii-P 
clock  device.  This  can  be  read  by  a  process,  using  the 
K„GKT_TIME  kernel  call. 

The  kernel  also  maintains  for  each  process  a  "slow"  clock. 
This  is  a  counter  in  tne  process'  communications  block  which 
is  Incremented  every  half-second.  Hy  settinq  variables  in 
its  communications  block,  a  process  can  arrange  for  the 
kernel  to  qive  it  (the  process)  an  "alarm"  notification 
after  a  specified  number  of  halt-second  ticks. 
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By  using  the  slow  clock  and  the  associated  alarm  mechanism, 
a  process  can  implement  any  sort  of  facilities  for 
maintaining  multiple  named  timers,  as  it  chooses.  Note  that 
using  the  slow  clock  and  the  alarm  mechanism  do  not  require 
system  calls.  The  associated  system'  overhead  is  thus  quite 
low. 

The  kernel  allocates  time  among  processes  by  time  slicing  at 
one-tenth  second  intervals. 


8.0  iaulaaaat.at.iaas  and  Results 

The  £>DC  kernel  has  so  far  been  implemented  on  the  PDP  11/70, 
11/34,  11/23  and  11/03.  (The  11/23  and  11/03 

implementations  are  modifications:  the  11/23  version  allows 
interrupts,  while  the  11/03  version  is  more  properly  viewed 
as  a  kernel  emulator.) 

The  code  is  written  in  a  modified  version  of  Pascal,  as  used 
in  the  UCLA  kernel,  with  small  amounts  of  assembly  language. 

The  11/70  version  of  the  code  comprises  approximately  2500 
Pascal  statements,  including  drivers  for  the  DHii,  UL11, 
PX0 1 ,  RP05 ,  TE1 6 ,  and  other  devices.  This  becomes 
approximately  30000  bytes  of  instructions.  (Total  kernel 
size,  including  all  tables,  is  extremely  dependent  on  the 
system  being  configured:  the  number  of  processes,  the  sizes 
of  their  capability  lists,  the  number  of  queues,  etc.) 

The  times  required  for  some  kernel  calls  is  shown  below. 
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1 1/70 

11/34 

K.GET.T1ME 

(Head  fast  clock.) 

0.81 

1.8 

mi  1 1  i  seconds 

K_GLT_DATA_hl.no 
(Get  block  and 
map  It  in.) 

1  .5 

/.I 

mi  1 1 1  seconds 

K_LM)UtUF 
(Put  block  on 
queue . ) 

1  .7 

3.1 

mini  seconds 

K_D£gUEUF 
(Get  block  oft 
queue  and  mao 
it  in.) 

1  .9 

3.5 

ml  1 1 1  seconds 

K_KELEASE_DAT  A_HLOCK 
(Clear  block  and 
return  to  pool.) 

2.0 

4.4 

milliseconds 

The  only  one  of  these  calls  which  has  an  equivalent  In  the 
Unix  system  is  the  K_GET_TIME  call.  The  Unix  "time"  system 
call  takes  .31  milliseconds  on  the  11/70.  13] 

we  can  use  these  numbers  to  get  estimates  of  the  Dandwidth 
of  the  enqueue/dequeue  interprocess  communication  path  under 
several  assumptions. 

First  of  all,  consider  the  following  situation: 


I  I  I  I  I  I 

I  A  I - >1  b  1 - >|  C  I 

(  I  I  t  I  I 


Here,  we  are  supposing  that  the  blocks  are  prepared  by  A, 
processed  by  b,  and  consumed  and  released  Dy  C.  The  total 
kernel  call  overhead  associated  with  B  receiving  and 
transmitting  one  128-byte  block  is 


[3]  All  times  discussed  below  will  be  for  the 
11/70,  unless  specified  otherwise. 
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r  i rr- e  tor  K-UF'O'iEilii  1.9  ms 

time  tor  K-F.hyUEUE  1.7  ms 

total  j.b  ms 

This  corresponds  to  a  throughput  of  aoout  35K  bytes  per 
second . 

A  second  situation  is  the  following: 


I  I  I  I 

|  a  I - >  i  h  I 

I  I  I  I 


Here,  we  suppose  that  A  gets  a  block,  orepares  a  message, 
and  enqueues  the  block  to  b.  b  dequeues  the  message,  reads 
it,  and  then  releases  the  block.  The  total  kernal  call  time 
per  126-byte  block  here  is 


time  for  K_GL !_DATA_bLOCK  1.5  ms 
time  for  K_Ei»yUKUE  1.7  ms 
time  for  K_bEyiJEUE  1.9  ms 
time  for  K_HtLEASE„UATA.HLOCK  2.0  ms 


total  7.1  ms 


This  corresponds  to  a  throughput  of  aoout  1BK  bytes  per 
second . 

This  calculation  does  not  allow  for  the  time  necessary  to 
switch  processes  so  as  to  allow  A  and  R  to  both  run,  and 
tnus  may  seem  unduly  optimistic.  However,  it  is  actually 
quite  realistic,  when  a  system  is  heavily  loaded,  as  is  the 
case  of  Interest  for  throughput  calculations,  process  A 
would  typically  have  a  number  of  external  events  to  process 
wnen  it  wakes  up.  A  will  then  process  all  of  these  events, 
producing  a  number  of  blocks  which  it  enqueues  to  Ft,  before 
it  (A)  goes  to  sleep,  letting  B  run.  B  then  will  process  all 
these  input  blocks  at  one  scheduling.  Thus  the  time 
required  to  switen  from  A  to  B  is  divided  among  this  number 
of  blocks,  and  so  does  not  greatly  affect  the  throughput. 

The  time  required  to  switch  processes  is,  however,  of  some 
interest.  The  experiment 
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I  I  I  I 

|  a  | - -->|  H  I 

I  I  I  I 


was  re-run  in  such  a  way  as  to  force  h  to  be  scheduled  every 
time  A  sent  one  block.  The  lollowinq  figure  shows  the  times 
used  to  send  one  block.  Note  that  both  processes  used  the 
standard  "main";  the  test  did  not  separate  out  the  time  in 
main  from  the  time  actually  in  the  kerne). 

<-----  Process  A  ----->  < - Process  B  -----> 

Enqueue  Kernel  Dequeue 

I  I  I 

Get  I  Exit  I  Enter  I  Release 

block  I  main  I  main  I  block 

III  I  III 

V  V  V  V  V  V  V 

I . I . I . I . —  I . I . . . 

<  1.5  >  <  1.7  >  < -  10  - >  <  1.9  >  <  2.0  > 


< - - ...  n  — . 

This  shows  a  worst-case  time  of  17  milliseconds  for  a  128- 
byte  blocK.  This  corresponds  to  a  throughput  of  7.5K  bytes 
per  second. 

It  should  be  remembered  that  these  throughputs  are  based  on 
the  use  of  128-byte  blocks,  as  in  our  current 
implementations.  The  use  of  larger  blocks  would  be  a  minor 
cnange,  and  would  result  in  Droportionally  larger 
bandwidths,  since  kernel  call  times  are  Independent  of  the 
size  of  the  block.  [4]  For  example,  if  256-byte  blocks  were 
used,  the  throughputs  above  would  nearly  double,  giving 
values  of  70K,  36K,  and  lbK  bytes  per  second. 

In  considering  these  speeds  and  throuohputs,  it  should  also 
be  pointed  out  that  the  SDC  kernel,  although  it  has  been  in 
use  for  some  time,  has  not  been  extensively  worked  over  to 
Increase  its  speed.  Effort  in  this  area  would  undoubtedly 
pay  off. 


C 4 1  with  the  exception  of  the  K. RELEASE. DATA. BLOCK 
call . 
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In  comparison,  the  throughput  of  a  Unix  nine ,  on  an 
otherwise-idle  11/70,  is  about  25K  bytes  per  second.  This 
is  the  rate  when  a  sending  process  sends  in  units  of  129 
bytes.  Increasing  the  send  unit  to  1280  bytes  leaves  the 
throughput  rate  approximately  unchanged. 


9.0  U&aial  at  Service 

The  SDC  Kernel  does  not  attempt  to  deal  with  denial-of- 
service  threats.  That  is,  a  malicious  process  could  cause 
CPU  usefulness  to  be  so  degraded  that  the  CPU  could  perform 
no  useful  worK.  For  example,  a  process  could  (potentially 
Dut  improbably)  get  and  Keep  a  large  numoer  of  blocKs. 
(This  threat  is  somewhat  limited:  a  process  cannot  get  more 
dIocks  than  It  has  slots  in  its  capability  list.  This  is  a 
per-process  parameter  in  the  superiinxer  control  file.) 

Facilities  could  be  added  to  the  SDC  Kernel  to  address  some 
denial-of-ser vice  issues,  out  it  should  be  pointed  out  that 
it  is  consistent  with  tne  objects  of  the  SDC  Kernel  not  to 
worry  about  denial-ot-servlce  issues.  The  reason  is  that 
there  are  no  "optional"  processes  in  a  communications 
processor  of  tne  Kind  that  the  Kernel  was  constructed  to 
support.  That  is,  the  correct  functioning  of  each  process 
is  necessary  for  the  system  to  provide  correct  service.  If 
any  process  is  not  performing  its  tasxs  correctly,  service 
will  be  denied,  and  the  Kernel  cannot  do  anythina  about  it. 
However,  security  is  preserved  regardless  of  service 
denials . 


lo.o  Cuxrfiui  StaJLus 

The  SDC  Kernel  was  coded  several  years  ago.  It  is  currently 
operational  for  the  Department  of  Defense  on  a  number  of 
CPUs  functioning  as  special  communications  controllers  and 
networK  front  ends  tor  AkPANb'I -1  i Ke  packet  networK  terminal 
and  host  interfaces,  uur  experience  so  tar  shows  that  the 
resulting  system  provides  throughput  wnicn  is  competitive 
with  other  systems  not  using  a  Kerneiizeo  arch  i  t ect ore  . 
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THE  SDC  COMMUNICATIONS  KERNEL 


•  AIMED  AT  SUPPORTING  SECURE  COMMUNICATIONS  APPLICATIONS 

-  FRONT  ENDS 

-  TERMINAL  ACCESS  SYSTEMS 

-  ETC. 

•  TYPICAL  PROCESSES  RUNNING  SUPPORTED  BY  THE  KERNEL  WOULD  BE 
COMMUNICATIONS  PROTOCOLS,  ETC 

-  TCP 

-  IP 

•  SUBJECTS  OF  THIS  TALK: 

-  SECURITY  POLICY 

-  SOME  KERNEL  MECHANISMS 

-  CURRENT  STATUS  AND  RESULTS 
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FEATURES 

GENERAL  "KERNEL”  FEATURES: 

•  MINIMAL  OPERATING  SYSTEM,  PROVIDES 

-  PROCESS  ENVIRONMENT 

-  SCHEDULING 

-  HARDWARE  OPERATION 

-  DEVICE  DRIVERS 

-  INTERRUPT  HANDLING 

•  NON-INTERRUPTABLE 

•  INTENDED  TO  BE  VERIFIABLE 


•  CAPABILITY  BASED 


HOW  THE  HUMAN  SPECIFIES 
COMMUNICATION  PATHS 

{Placing  mto  the  kernel  hi*  decisions  about  need  to  communicate 
among  the  processes) 

THE  SUPERLINKER  CONTROL  FILE 

SAMPLE  SITU£  TION 

PROCESSES  A.  B.  C.  D 

QUEUES  X  V 
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HOW  THE  HUMAN  SPECIFIES 
COMMUNICATION  PATHS 

THE  SUPERLINKER  CONTROL  FILE 

system  OEMO 

cpu  is  in  It  70  wrtb  bytei  of  memory 


process  A 

wants 

enqueue  or  cess  to  queue  * 

code 

e  obj 

process  B 

wants 

dequeue  access  to  queue  X 

code 

ib  06) 

process  C 


PROCESS  STATES 


ASLEEP:  THE  PROCESS  HAS  NOTHING  TO  DO  AND  GETS  NO 
CPU  TIME  UNTIL  SOME  EVENT  EXTERNAL  TO  THE 
PROCESS  CAUSES  THE  KERNEL  TO  AWAKEN  THE  PROCESS 

AWAKE:  THE  PROCESS  WILL  GET  CPU  TIME. 

THE  AVAILABLE  CPU  TIME  IS  ALLOCATED  AMONG 
ALL  THE  AWAKE  PROCESSES  IN  A  ROUND-ROBIN 
FASHION,  IN  1/10-TH  SECOND  SLICES 
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PROCESS  VIRTUAL  ADDRESS  SPACE 


(IN  A  PDP  11/34) 


177777(81 
PAGE  7 
160000(8) 
PAGE  6 
140000(8) 
PAGE  5 
120000(8) 
PAGE  4 
100000(81 
PAGE  3 
60000(8) 
PAGE  2 
40000(8) 
PAGE  1 
2000018) 
PAGE  0 
00000(8) 


COMMUNICATIONS 

BLOCK 

(  'COMM  BLOCK  > 


MAPPABLE 


MAPPABLE 


MAPPABLE 


CODE  AND  DATA 


CODE  AND  DATA 


COOE  AND  OATA 


LIBRARY 


PROVIDES  COMMUNICATIONS 
BETWEEN  THE  PROCESS  AND  THE 
THE  KERNEL 


PAGES  NOT  USED  FOR  LIBRARY 
PROCESS  CODE  OR  DATA.  OR  THE 
COMMUNICATIONS  BLOCK  ARE 
MAPPABLE  PAGES  THERE  ARE  AT 
MOST  THREE  OF  THESE 


PROCESS  CODE  AND  DATA 
OCCUPY  AT  LEAST  THREE 
PAGES  MORE  IF  THE  PROCESS 
IS  LARGE 


PROCESS  GETS  READ  ONLY  ACCESS 
TO  COMMON  LIBRARY  SUBROUTINES 
(FOR  EXAMPLE.  SUBROUTINE  TO 
CONVERT  MACHINE  TIME  TO  HUMAN 
DATE  AND  TIME) 


KERNEL-TO-PROCESS  COMMUNICATIONS 

(II  BEFORE  EXTERNAL  EVENT 


COMM  _  COMM  SUMMARY  ^  FALSE 

BLOCK  COMM  TYPE  a  EVENT  =  FALSE 


- _ PROCESS  EXECUTING.  PROCESSING 

SOME  PREVIOUS  EVENT 


(2)  EVENT  OF  TYPE  a,  EXTERNAL  TO  THE  PROCESS.  OCCURS 


KERNEL  SETS 
VARIABLES 
IF  PROCESS 
WERE  ASLEEP. 
KERNEL  WOULD 
AWAKEN  IT 


COMM 

BLOCK 


COMM  SUMMARY  -  TRUE 
COMM  TYPE  a  EVENT  -  TRUE 


PROCESS  CONTINUES  EXECUTING. 
UNDISTURBED 


PROCESS  LOOKS  AT  ITS  COMM  BLOCK 

PROCESS  FINISHES  PROCESSING 
PREVIOUS  EVENT.  LOOKS  AT  COMM 
BLOCK.  CLEARS  VARIABLES 

COMM  SUMMARY  -  FALSE 
COMM  TYPE  a  EVENT  =  FALSE 

AND  BEGINS  PROCESSING  THE 
NEW  EVENT 


COMM 

BLOCK 
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PROCESS  TOP-LEVEL  LOOP 


PROCEDURE  MAIN 
BEGIN 

INITIALISE 
WHILE  (TRUE)  00 
BEGIN 

COMM  SUMMARY"  FALSE 

WHILE  (THERE  ARE  UNPROCESSED  EXTERNAL  EVENTS!  DO 
BEGIN 

If  (COMM  TYPE  a  EVENT i  PROCESS  a 
IF  (COMM  TYPE  b  EVENT)  PROCESS  b 

l  NO 

K  SLEEP 

END 

END 

If  COMM  SUMMARY  IS  TRUE  WHEN  THE  K  SLEEP  CALL  IS  MADE  THE  PROCESS  DOES 
NOT  ACTUALLY  SLEEP  THE  K  SI  EE P  CALL  RE  TURNS  IMMEDIATELY 
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PROCESS  PROGRAMMER'S  SETTING 


STANDARD  'MAIN'  PROVIDED  TO  EVERY  PROGRAMMER 

PROGRAMMER  WRITES  THE  PROGRAM  UNITS  CALLED  FROM  MAIN 
INITIALIZE  (INITIALIZE  PROCESS) 

PROCESS  a  (PROCESS  EXTERNAL  EVENTS  OF  TYPE  a) 

PROCESS  b  (PROCESS  EXTERNAL  EVENTS  OF  TYPE  b) 

PROGRAMMER  S  CODE  IS  NEVER  (LOGICALLY)  INTERRUPTED  THE  PROGRAMMER 
DOES  NOT  HAVE  TO  DEAL  WITH  RACE  CONDITIONS,  ETC 


THE  PROGRAMMER'S  CODE  MAKES  KERNEL  CALLS  DIRECTLY.  THERE  IS  NO 
ATTEMPT  TO  PROVIDE  A  FAMILIAR  PROCESS  ENVIRONMENT.  SUCH  AS  A 
UNIX  EMULATOR 


THE  PROGRAMMER  MUST  HAVE  SOME  UNDERSTANDING  OF  MEMORY 
MANAGEMENT  IN  ORDER  TO  USE  THE  INTERPROCESS  COMMUNICATIONS 
MECHANISMS 
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STATUS 


WRITTEN  IN  MODIFIED  PASCAL 
NOT  FORMALLY  SPECIFIED 
INTENDED  TO  BE  "VERIFIABLE" 
VERSIONS  FOR 

POP  11/70 
PDP  1  1/34 

PDP  11/23  (INTERRUPTABIE) 

PDP  11/03  (KERNEL  "EMULATOR"! 


SIZE 


11/70  VERSION.  INCLUDES  DRIVERS  FOR 
DH.  DL  (SERIAL  LINE  INTERFACES! 

RP  (DISK! 

RX  (FLOPPIES) 

TE  (TAPE) 

AND  MORE 

—2500  PASCAL  STATEMENTS 
—  30.000  BYTES  OF  CODE 

DATA  SPACE  SIZE  EXTREMELY  DEPENDENT  ON  THE  NATURE  OF  THE  SYSTEM 
NUMBER  OF  PROCESSES.  QUEUES  ETC 


IN  USE  SUPPORTING  FRONT  ENDS.  ETC.  FOR  A  SPECIAL  DoD  ARPANET  LIKE  SYSTEM 


r 

INDIVIDUAL  CALL  TIMINGS 

1 

ALL  TIMES  IN  MILLISECONDS 

11/34 

11/70 

11/70 

UNIX 

K  GET  TIME 

18 

0.81 

0  31 

K  GET  DATA  BLOCK 

2  7 

15 

K  ENQUEUE 

3.1 

17 

K  DEQUEUE 

3  5 

19 

K  RELEASE  DATA  BLOCK 

4  4 

2.0 

KERNEL  CALL  TIME  TO  SEND  ONE  128  BYTE  DATA  BLOCK 

11/34 

11/70 

11/70 

UNIX 

K  GET  DATA  BLOCK 

2  7 

1  5 

K  ENQUEUE 

3  1 

1  7 

K  DEQUEUE 

3  5 

1  9 

K  RELEASE  DATA  BLOCK 

44 

2  0 

13  7 

7  1 

DEDUCED  BANDWIDTH  IBYTES/SEC) 

9  3K 

18K 

~  25K  (PIPE) 

KERNEL  BANDWIDTH  WOULD  INCREASE  PROPORTIONALLY  IF  BLOCK  SIZE  WERE 

|  INCREASED  PAST  128 

UNIX  PIPE  BANDWIDTH  SAME  IF  READS  AND  WRITES  WERE  DONE  IN  UNITS  OF 

1  280  BYTES  INSTEAD  OF  1  28 
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SCHEDULING  SPEED 


ENQUEUE  KERNEL  DEQUEUE 


(ALL  TIMES  FOft  11/70,  IN  MILLISECONDS) 


SUMMARY 


•  OPERATIONAL  FOR  A  NUMBER  OF  YEARS 

•  HOPEFULLY  VERIFIABLE  OPERATING  SYSTEM  KERNEL. 

•  REASONABLE  SPEED  IN  CLASSIFIED  DoD  APPLICATIONS. 

COMPETITIVE  WITH  NON-KERNEL  SYSTEMS. 

•  REASONABLY  HOSPITABLE  ENVIRONMENT  FOR  A 

COMMUNICATIONS  SYSTEM 
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MITRE  IR&D 
Project  95130 
Secure  Packet  Switch 


Chris  Hi  soon 
The  MITRE  Cor{*orat  ion 


Motivation 

•  Survey  of  Commercial  Architectures 

•  Exploration  of  Multiprocessor  Machines  and  the  Impact  of 
Security  Kernels  on  Them 

•  Impact  of  Multiprocessors  on  Security  Kernels 

Problem 

•  Verification  of  Large  Amounts  of  Software 

•  Performance  Overhead  of  the  Security  Kernel 

•  Economics  of  Minicomputer  Based  Switch 

•  Survivability  of  Few  Node  Network 


Approach 


•  Functional  Partitioning  of  Packet  Switching  Tasks 

•  Assignment  of  One  Processor  per  Function 

•  Interprocessor  Communication  Minimized 

•  Processors  that  Handle  More  Than  One  Packet 
Simultaneously  Will  Have  Their  Code  Verified 

•  Most  Processors  Handle  One  Packet  at  a  Time  and  Then 
Have  Their  Memory  Scrubbed  Before  Handling  the  Next 
Packet 

•  The  Functional  Partitioning  and  Communication  Limitations 
Enforce  the  Security  Policy 

•  Modular  Node  with  Many  Microprocessors  Ensures 
Survivability  at  Lower  Cost 


Model  Switch 


To/From  To/From 

Hosts  Network 


Host  Pod 


Packet  Output  m mmm — _ 
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Microprocessor  Usage 


•  Microprocessors  Per  Pod 

—  Network  Pod:  9 
—  Host  Pod:  10 

—  Control  Pod:  15 

•  There  Are  Only  Four  Classes  of  Processor 

—  Packet  Processor 
—  Packet  Butter 
—  Control  Elements 
—  Fake  Hosts 


Microprocessor  Usage,  Continued 


Microprocessors  for  an  Arpanet  Style  Packet  Switch 
Node 

—  4  Trunk  Lines 

—  4  Host  Lines 


Translates  To 


—  8  Network  Pods 

-  6  x 

9  = 

54  Microprocessors 

—  6  Host  Pods 

-  6  x 

10  - 

60  Microprocessors 

—  2  Control  Pods 

-  2  x 

15  = 

30  Microprocessors 

Total 

144  Microprocessors 

Open  Technical  Issues 


•  Serial  Bus  or  Parallel  Bus 

•  16/32  Bit  Bus  (Motorola  VersaBus,  Zilog  Z-Bus, 

Intel  Multibus) 

•  Performance  as  Function  of  Load  for  Various  Access 
Protocols  (e.g.,  Polling,  Contention,  TDMA) 

•  Bus  Choice  Must  Satisfy  Requirements  for  Control, 
Addressing,  and  Data  Transfer 


Conclusions 


The  Design  is  Feasible 

The  Design  Benefits  from  AUTODIN  II  Experience 

The  Design  is  a  Hardware  Casting  of  the  Trusted 
Computing  Base 

The  Design  Has  Less  Software  to  Verify  than  a 
Comparable  Switch 

Special  Purpose  Multi-Microprocessor  Switches  Have  Been 
Built  Commercially 


EXPERIENCE  WITH  KVM 


:  V.  II  INK  I 


SYSTEM  DEVELOPMENT  CORPORATION 
SANTA  MONICA,  CALIFORNIA 
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OVERVIEW 

•  KVM  IS  A  GENERAL  USE  SYSTEM 

•  KVM  IS  DESIGNED  FOR  LEVEL  4  CERTIFICATION 

•  KVM  ARCH  I  TECTURAL  STATUS 

•  KVM  OPERATIONAL  STATUS 

Byatem  Davalopmant  Corporation 
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KVM  IS  A  COMPLETE  SYSTEM 


•COMPATIBLE  WITH  POPULAR  UNMODIFIED 
OPERATING  SYSTEMS 

O/S  DOS 

CMS  MVS 

M  V  T  ETC. 

•SUPPORTS  EXISTING  APPLICATIONS 

FORTRAN  JOVIAL 

PL/I  ASSEMBLER 

TEXT  EDITORS  DATA  MANAGEMENT  SYSTEMS 
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KVM  IS  DESIGNED  FOR  LEVEL  A  CERTIFICATION 

•KERNELIZED  ARCHITECTURE 

•ENFORCES  DoD  SECURITY  POLICY 

•FORMAL  VERIFIED  SPECIFICATIONS 

•  CORRESPONDENCE  BETWEEN  SPECIFICATIONS 
AND  CODE 
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KVM  ENFORCES  DoD  SECURITY  POLICY 

•  MANDATORY 

A  HIERARCHICAL  LEVELS  +  62  COMPARTMENTS 

•  DISCRETIONARY 

ACCESS  CONTROL  LISTS  +  PASSWORDS 
•MULTI-LEVEL  ACCESS  TO  MINIDISKS 
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VERIFIED  FORMAL  SPECIFICATIONS 


•SPECIFICATIONS  WRITTEN  IN  INA  JO  ™  FOR 
ALL  TRUSTED  CODE 

•  VERIFIED  TOP  LEVEL  SPECIFICATIONS 

-  780  LINES  OF  SPECIFICATIONS 

-  A  9  A  PAGES  OF  PROOF  EVIDENCE 

•  VERIFIED  SECOND  LEVEL  SPECIFICATIONS 

-  2,910  LINES  OF  SPEC  I  F  I  CAT  I  ONS 

-  PROOFS  ARE  IN  PROGRESS 
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SPECIFICATION-TO-CODE  CORRESPONDENCE 


1.  MAP  INA  JO  CONSTANTS  i  VARIABLES  TO  JOVIAL  DATA. 

2.  MAP  INA  JO  TRANSFORMS  TO  JOVIAL  PROCEDURES. 

3.  MAP  INA  JO  ASSERTIONS  TO  JOVIAL  SECURITY  CHECKS. 

4.  MAP  INA  JO  TRANSITIONS  TO  JOVIAL  ASSIGNMENT 

STATEMENTS . 

5.  RESOLVE  DISCREPANCIES. 

6.  VERIFY  ALL  SECURITY  CHECKS  ARE  PERFORMED  BEFORE 

ANY  ASS IGNMENTS  ARE  MADE  . 

7.  AUDIT  UNMAPPED  SOURCE  CODE  FOR  SECURITY-RELEVANT 

CODE. 
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ARCHITECTURAL  STATISTICS 
VM/570  REL  3  P  L  C  15 

134  MODULES  150,000  LINES  ASSEMBLER  CODE 


FUNCTIONAL  AREA 

modules 

TOTAL  LINES 

C0MP00LS 

4  7 

3,139 

JOVIAL 

KERNELS 

107 

11,590 

J0VIA1/ASMB 

AUTHORIZATION 

32 

3,637 

JOV  I  A  l 

ACCOUNTING 

2 

204 

JOVIAL 

OPERATOR 

22 

2,017 

J  0  V  I  A  L  7  A  5  •  B 

UPDATER 

.264 

*  TRUSTED 

2  1  3 

2  0  ,  8  2  1 

NKCP 

116 

179,754 

GLOBAL  PROCESSES 

_2  0 

1  7,2  3 0 

untrusted 

126 

146,484 

UNDER  DEVELOPMENT 
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KVM  ARCH  I TECTURAl  STATUS 


KVM  IMPLEMENTS 

•  MESSAGE  PROTOCOL  DRIVEN  SYSTEM 
-  INTERNAL  COMMUNICATION 


•  MULTI-LEVEL  RELATIONAL  DBMS 

-  USER, DEVICE, PROFILE  DIRECTORIES 


•CAPABILITY  BASED  SYSTEM 

-  ACCESS  PERMITTED  ONLY  IF  USER  HAS  A  "GRANT 


•ABSTRACT  DATA  TYPE  MONITORS 
-  NO  CENTRAL  SYSTEM  TABLES- 
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KVM  OPERAT I ONAL  STATUS 


•  undergoing  formal  detailed  system  testing 

-  SYSTEM  DEVELOPMENT  CORPORATION  IBM  1331-11 

-  NAVAL  AIR  TEST  CENTER,  AMDAHL  V  7 / A 

•IN  PROGRESS  t  CONTINUING  NEXT  12  MONTHS  WITH 
NEW  FEATURES 
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OPERATIONAL  PERFORMANCE 


•  CONTRACTUAL  MEASUREMENT  TASK 


•  ESTABLISH  MEANINGFUL  BENCHMARKS 


•  CONTRAST  THROUGHPUT  OF  VM  vs  KVM 
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PROJECT  SUPPORT 

NAVELEX 

KERNEL  AND  HARDWARE  DLVELOPMFNT 

TRUSTED  SOFTWARE 

TCP 

HONEYWELL 

KERNEL  INTERFACE  PACKAGE 
1822  IMPLEMENTATION 
HARDWARE  PRODUCT  DEVELOPMENT 


Honoywell 


PROGRAM  OBJECTIVES 

•  DEVELOP  ADDON  HARDWARE  TO  COMMERCIAL 
LEVEL  6  WHICH  MAKES  IT  EASIER  TO  BUILD 
SECURE  SYSTEMS 

•  DEVELOP  TRUSTED  COMPUTER  BASE 
(TCB)  SOFTWARE 

ENFORCES  DOD  SECURITY  POLICY 
FORMALLY  PROVABLE  (7LSONLYI 
■  SUPPORTS  VARIOUS  APPLICATIONS 

•  DOD  CERTIFICATION 

•  DEVELOP  THE  SCOMP  PRODUCT 


POTENTIAL  APPLICATIONS 

•  freestanding  time  sharing  system 

•  GUARD  BETWEEN  TWO  NETWORKS  AT  DIFFERENT 
SECURITY  LEVELS 

•  SECURE  NETWORK  FRONT  END 

•  SECURE  DATA  BASE  MACHINE 

•  MILITARY  MESSAGE  SWITCH 

•  SECURE  WORD  PROCESSOR 
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SCOMP  HARDWARE  BASE 

•  level  5  MINICOMPUTER 

•  ScCUR'Tv  POOTECTION  MODULE  iSPMI 

•  VIRTUAL  MEMORY  INTERFACE  UNIT  VMIU1 

•  ie22ACLA  LINE  ADAPTER 

•  STANDARD  LEVEl  6  PERIPHERALS 


SPM  +  LEVEL  6  MINICOMPUTER  =  SCOMP 
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SECURITY  PROTECTION  MODULE  FEATURES 

•  f  AST  PROCf  '  .SSWIICHINO 

phocfssi)i  si  riptor  mrr  of  f inition  via  descriptor 
RASE  HOOI 

AUfOl  OADOF  1)1  SCRIP  TOMS 

•  1UEVEI  Ml  MORY  RESCRIPT  OR  SYSTEM 

R.  W  V  ( :ON  I  ROl  A  T  AN  Y  l  r  vn 
SEGMf  NTS  i"K  WORDS 
PAGF  S  t;’H  WORDS 

•  I  O  MEDIAN'  'N 

CPU  TO  1)1  VICE 
DEV  1C. I  m  MEMORY 

•  MUI  1IOS  I  IK i  RING  STRIK  IllRF 

7  PRIVIl  I  (il  D.^fJON  PRIVIl  fCiED  RINGS 
READ.  WRUE.  FXf  CUTE’.  AND  CAI  l  BRAOKf  TS 
FTINC i  CRO'V  ilNl SIJPP(  )R  T  INS  I  Rl ICTIONS 

•  PAC.f  F  AUI  I  nrcf^VFRY  SUPPORI 


KSOS6  SOFTWARE 

•  SECURITY  KERNEL 

•  TRUSTED  S*  )FTWARE 

•  SCOMP  KERNEL  INTERFACE  PACKAGE 

•  TRANSMISSION  CONTROL  PROTOCOL  (TCP) 
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KSOS-6 

TRUSTED  SOFTWARE 

•  USER  SERVICES 
•  SECURE  INITIATOR 
SECURE  SERVERS 

ACCESS  AUTHENTICATION  FUNCTIONS 
LOGIN 

CHANGE  GROUP 

SET  ACCESS  LEVEL 

CHANGE  DEFAULT  ACCESS  LEVEL 

LOGOUT 

■  FILE  DISPLAY  AND  ACCESS  MODIFIER 
PASSWORD  MODIFIER 
81  26  13 

HonoywHI 
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KS0S6 

TRUSTED  SOFTWARE  (CONT) 

•  OPERATIONS  SERVICES 

■  SECURE  STARTUP 

■  AUDIT  COLLECTION 
SECURE  LOADER 
OPErATOR  COMMANDS 
SET  SYSTEM  CLOCK 
SWITCH  ACCOUNTING  FILES 
CHANGE  DEVICE  ACCESS 
SET  OISK  DEVICE  STATUS 
SYSTEM  SHUTDOWN 


Honoywi‘11 
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TRUSTED  SOFTWARE  (CONT) 

•  MAINTENANCE  SERVICES 
MAKE  FILESYSTEM 
TRUSTED  DATABASE  EDITORS 
USER  ACCESS 
GROUP  ACCESS 
TERMINAL  ACCESS 
SECURITY  MAP 
MOUNTABLE  FILESYSTEMS 
FILESYSTEM  DUMP 
FILESYSTEM  RESTORE 
FILESYSTEM  CONSISTENCY  CHECK 
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SCOMP  KERNEL  INTERFACE  PACKAGE 
(SKIP) 

•  PURPOSE 

•  PROVIDE  AN  EFFICIENT  LOW  LEVEL  INTERFACE 
FOR  USE  BY  APPLICATIONS  SOFTWARE 

■  PROVIDE  A  HIERARCHICAL  FILESYSTEM 
PROVIDE  PROCESS  CONTROL 

'  •  ATTRIBUTES 

•  CODE  RESIDES  IN  KERNEL  ADDRESS  SPACE 
WITH  RING  2  EXECUTE  PERMISSIONS 

•  ACTS  AS  A  FILTER  FROM  USER  RING  TO  KERNEL 
GATES  TO  PROVIDE  FILESYSTEM  AND  PROCESS 
CONTROL  INTEGRITY 

Honeywell 


SKIP 

FILE  SYSTEM  FEATURES 

•  ENTRY  NAMING  SYSTEM 

•  MONOTONICALLY  INCREASING  SECURITY 

•  INCREASE  SECURITY  LEVEL  THROUGH 
UPGRADED  DIRECTORY  OR  FILE 

•  MULTICS  LIKE  LINK  SUPPORT 

•  FILESYSTEM  INTEGRITY  MAINTAINED  IN  RING  2 

•  NO  PATHNAME  AWARENESS 

•  FILE  DATA  MANIPULATION  IN  USER  RING 


Honeywell 


SKIP 

PROCESS  CONTROL  FEATURES 

•  PROVIOE  CLASSICAL  EVENT  WAIT/NOTIFY 
SYNCHRONIZATION 

•  ALLOW  SPAWNING  OF  CHILD  PROCESSES 

•  PROVIDE  MECHANISM  BY  WHICH  USER  RING 

'  CODE  CAN  HANDLE  INTERRUPTS  AND  FAULTS 

-  1  '■  I  » 
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KSOS-11 
Summary  And 
Update 


John  Woodward 
The  MITRE  Corporation 


KSOS-11  History 
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KSOS  Summary  and  Update  —  Overview 


Project  Goals 
Project  Status 

Insights  Into  Trusted  Computing 


Project  Goals  —  KSOS 
Requirements  Summary 


Production  -  Quality  System 

Provable  Security 

UNIX  Compatibility 

Efficiency  Comparable  With  UNIX 

Administrative  Support  Features 

General-Purpose  Kernel 

Broad  Applicability 
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Project  Goals  —  KSOS  Kernel 
Architecture 

Functions 

Prot  esses 

Segments 

1  O 

fork  invoke  spins n 

build  release 

device  funi  lion 

release 

remap 

mount  unmount 

post  receive  message  rendezvous 

create  file 

signal 

open  c  lose 

interrupt  return 

link  unlink  file 

walk  ptoc  t’ss  table 

read  write  bloc  k 

nap 

hoof 

ball 

gel  set  status 

get  set  status 

get  siu  status 

gel  set  level 

get  set  level 

get  set  lev  el 

Project  Goals  —  KSOS  Kernel 
Architecture 

Non-Kernel  System-Related  Software 


l  «er  Services 

set  ure  initiator 
secure  server 
login  lii(]oul 
lilt'  at  tess  modifier 
<  hanqe  access  level 
t  hanqe  group 
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Operations  &  Maintenance 

lile  svstem  clump  restore 
pat  k  imtiaii/ation 
extent  initialization 
moditv  control  entrv 
tonstslantv  t  he(  kers 
bool  c  opv 

level  preserving  c  opv  prinl  directory  manaqer 
secure  mat)  network  i  oniroliers 

svstem  startup  shutdown 
svstem  generation 
process  booistrappei 
mount  unmount 
assign  deassiqn  device 
line  printer  spooler 
kernel- to  pathname  mapper 


Administration 

immiqrat  urn 
uset  c  unt  ml 
priv  tleqe  i  onltol 
set  utn  v  map 
terminal  pmlile 
dev  n  e  profile 
svstem  ptoble 
audit  t  aptiire 


Project  Goals  —  KSOS  Security 
Assurance 


FORMAL 

TESTING 


Project  Status  —  Versus  Requirements 


Production  -  Quality  System 

Provable  Security 

UNIX  Compatibility 

Efficiency  Comparable  With  UNIX 

Administrative  Support  Features 

General-Purpose  Kernel 

Broad  Applicability 


Project  Status  —  Provable  Security 


Design  Proofs 

Spec  Checking 
Theorem  Proving 
Analysis  of  False  Theorems 
Flow  Analysis 

Code  Proofs 

Example  module  only 


Project  Status  —  KSOS 
Efficiency 


Performance 

Size 


Project  Status  —  KSOS 
Implementation  Completion 


Kernel 

95 

Emulator 

90 

NKSR 

65 

TCP 
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Insights  Into  Trusted  Computing 


Modula  As  the  Implementation  Language 

Multiple  Representations 

Formal  Methods 

Hardware  Base 
Security  Model 


Insights  Into  Trusted  Computing 

It  Can  Be  Done! 

Importance  of  Corporate  Commitment 

Utility  and  Benefits  of  Formal 
Specifications 

Need  for  More  Experience  in  Code  Proofs 


Need  for  Additional  Tools  and  Concepts 


ACCAT  GUARD 

FUNCTIONAL  DESCRIPTION  -  TRANSACTIONS 

IHANSACTION  ORIENTED 

A l  L  VRANSACI  IONS  ARE  SUBMITTED  VIA  "NETWORK  MAIL’ 
ALL  RESULTS  ARE  Ht  TURNED  VIA  "Nfc  TWORK  MAH  " 

SIX  JHANSAl.  \  ION  T  YPI  S 

IOW  III  HIGH 
MAIL 

"CANONIOAl  OUCHY 
l  Nlil  ISH  OUt  HY 

HR ilt  lo  (  OW 
MAII 

"l.ANONM.Ai  OUt  HY 


I  Nlil  ISH  Dili  HY 


ACCAT  GUARD 


FUNCTIONAL  DESCRIPTION  -  PERSONNEL 

•  SECURITY  WATCH  OFFICER  (SWO) 

VIEWS  ALL  HIGH  TO  LOW  DATA  I  HANSEL  HS 

INTERFACES  WITH  TRUSTED  SOFTWARE  ”  FOR  DOWNGRADING”  OF  DAI  A 

•  SANITIZATION  PERSONNEL  ISP) 

SANITIZES  LOW  TO  HIGH  QUERY  RESULTS 
TRANSLATES  ENGLISH  QUERIES  TO  -CANONICAL”  FOHM 
INTERFACES  WITH  "HIGH  SIDE”  U'.'TRUSTED  SOFTWARE 


ACCAT  GUARD 


SECURITY  POLICY 


•  DATA  SEPARATION  (DoD  SECURITY  MODEL) 

SIMPLE  SECURITY  CONDITION  ("READ"  RULE) 
•  PROPERTY  CONDITION  {"WRITE”  RULE) 
TRANQUILITY  CONDITION  ("ALTER”  RULE) 


KSOS 

ENFORCED 


•  DATA  INTEGRITY  ("DUAL  ”  OF  DoD  SECURI?  Y  MODEL  ) 


•  DISCRE  I IONAHY  ACCESS  (A  l  A  UNIX) 


•  MANUAL  DOWNGRADE  POl  ICY  (VIOLATES  *  PHOPEIUY) 
SECURITY  WATCH  OFFICER  (SWO)  VII  WS  At  l  DATA 
SWO  ACCEPTS  DOWNGRADE 
SWO  CONFIHMS  DECISION 


TRUSTED 

SOFTWARE 

ENFORCED 


•  AUDIT  Al  L  HIGH  TO  LOW  DOWNGN -\DE S 


ACCAT  GUARD 


’.ANrn/i  h 
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WArrn 
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ACCAT  GUARD  SOFTWARE  CONFIGURATION 


ACCAT  GUARD 


STATUS:  PRESENT  AND  FUTURE 

PRESENT 

.  HARDWARE  INSTALLED  AT  NAVAL  OCEAN  SYSTEMS  CENTER  INOSC) 

•  Al  l  SOFTWARE  COMPLETED  -  OEMONSTRATABLE  UNDER  UNIX 
a  TRUSTED  SOFTWARE  FORMALLY  SPECIFIED  AND  VERIFIED 

•  THHEAT/VULNERABILITY  ANALYSIS  COMPLETED 

•  KSOS  11  INSTALLATION  UNDERWAY 

(  U  TURJ 

•  KSOS  6  INSTALLATION  PLANNED 

•  AUTOMATED  SANITIZATION/TRANSLATION  ELIMINATES  SANITIZER 
>  VERIFICATION  OF  AUTO  SANITIZATION  El  IMINATES  SWO 

•  OTHER  IOW/HIGH  HOST  SUPPORT  PLANNED 


FORSCOM  GUARD 


FORSCOM  GUARD 


THE  PROBLEM 


FORSCOM  GUARD 

THE  SOLUTION 


► 


FORSCOM  GUARD 

FUNCTIONAL  DESCRIPTION 

’INTERACTIVE"  ORIENTED 

MEDIATES  BETWEEN  AIL  LOW  USER  AND  HIGH  SYSTEM  DIALOGUES 

PROVIDES  BOTH  MANUAL"  AND  AUTOMATIC"  DOWNGRADE  MECHANISMS 

PROVIDES  LOW  USER  INPUT  "FILTER"  MECHANISM 

SCREENEH  PERSONNEL 

VIEWS  ALL  "MANUAL"  HIGH  TO  LOW  DATA  TRANSFf  RS 


INTERFACES  WITH  TRUSTED  SOF TWARE"  FOR  "DOWNGRADING"  OF  DATA 


r 


FORSCOM  GUARD 

SECURITY  POLICY 

•  DATA  SEPARATION  (DoD  SECURITY  MODEL) 

SIMPLE  SECURITY  CONDITION  ("READ'*  RULE) 

•  PROPERTY  CONDITION  ("WRITE”  RULE) 

-  TRANQUILITY  CONDITION  ("ALTER"  RULE)  •  KS0S 

ENFORCED 

•  DATA  INTEGRITY  ("DUAL"  OF  DoD  SECURITY  MODEL) 

•  DISCRETIONARY  ACCESS  (A  LA  UNIX) 


•  MANUAL  DOWNGRADE  POLICY  (VIOLATES  •  PROPERTY)  X 

SCREENER  VIEWS  ALL  DATA  I 

SCREENER  ACCEPTS  DOWNGRADE  1 

SCREENER  CONFIRMS  DECISION  I 


•  AUTOMATIC  DOWNGRADE  POLICY  (VIOLATES  * -PROPERTY) 
ALL  DATA  IS  RECOGNIZABLE  IN  PROPER  CONTEXT 
"BANDWIDTH"  NOT  EXCEEDED 


> 


TRUSTED 

SOFTWARE 

ENFORCED 


•  ACCEPT  USER  INPUT  POLICY  (A  "FILTER") 

DATA  IS  RECOGNIZABLE  IN  PROPER  CONTEXT 


•  AUDIT  ALL  HIGH  TO  LOW  DOWNGRADES 


FORSCOM  GUARD 

HARDWARE  CONFIGURATION 


*  HIIHIHb 
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FORSCOM  GUARD 

SOFTWARE  MECHANISMS 


FORSCOM  GUARD 

STATUS:  PRESENT  AND  FUTURE 


PRESENT 

•  HARDWARE  INSTALLED  AT  FORCES  COMMAND.  FT  GILLEM 

•  SOFTWARE  OPERATIONAL  DEMONSTRATABL  E  UNDER  UNIX 

•  FORMAL  SPECIFICATION  OF  TRUSTED  SOF TWARE  UNDE HWAY 

FUTURE 

•  KSOS  11  INSTALL  ATION  PLANNED 

•  VERIFICATION  OF  T  RUST  ED  SOF  TWARF 


•  OTHER  WWMCCS  APPl  ICATIONS  PI  ANNFD 


A  Security  Model  for  a  Military  Message  System 


Carl  E.  Landwehr 


Computer  Science  and  Systems  Branch,  Code  7590 
Information  Technology  Divison 
Naval  Research  Laboratory 
Washington,  D.C.  20375 


[Portions  of  this  work  were  sponsored  by 
the  Naval  Electronics  Systems  Command, 
Code  8144,  H.  O.  Lubbes.] 


Outline 

What  security  models  are  good  for 

History  of  security  models 

Experience  with  Bell  and  LaPadula  model 

to  application-based  approach 

Security  model  for  a  military  message  system: 

Current  version 
Definitions 
Model  of  operations 
Security  Assumptions 
Security  Assertions 

Regimes  for  accessing  objects  within  containers 
Outstanding  Issues 
Plans 
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What  security  models  are  good  for 


Define  what  "security"  means  in  a  given  system 
Provide  basis  for  understanding  system  operation 
Provide  basis  for  proofs 


History  of  security  models 

Operating  system  protection  models 
Models  incorporating  DoD  security 
Access  Control  (Bell  and  LaPadula) 
Information  Flow  (Denning) 

Revised  Bell  and  LaPadula 


Experience  with  Bell  and  LaPadula  model 

MME  -  trusted  job 
KSOS  -  NKSR 

Guard  -  trusted  processes 
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An  application-based  approach 
User's  view  of  the  system 


Components  of  an  application-based  model 
Definition  of  terms 
Model  of  operations 
Assumpt ions 
Assertions 

How  the  model  can  be  used 

Current  version  of  the  MMS  model 
Definitions 

Classification  -  disclosure  and  modification  levels 

Clearance  -  user  disclosure  level 

User  ID  -  one  per  user 

Role  -  function  performed  by  user 

Access  control  list  -  pairs  (Uset ID  or  Role,  Access  mode) 

access  modes  include  read,  write,  execute, 
may  be  attached  to  objects,  containers 

-  smallest  unit  with  explicit  classification 
(single  level) 

-  has  classification  and  may  contain  objects 
or  other  containers  (multi-level) 

-  object  or  container.  Each  entity  can  be 
designated  by  unique  ID  or  pathname 

-  sequence  of  machine-executable  instructions 
may  have  an  associated  clearance  and  User  ID 

-  a  particular  type  of  container 


Object 

Container 

Entity 

Program 

Message 


Examples  of  objects 

Date-time  group 

Subject 

Precedence 


Examples  of  containers: 

Text 
Message 
Message  Pile 


Entities  that  might  be  containers  in  one  system  and  objects  in  another 

Mdress  list 
Comments 


Sore  operations  applicable  to  messages 


Compose 

Output 

Send 

Forward 

Coord inate 

Readdress 

Delete 

Destroy 


Edit 

Update 

Release 

Distribute 

Chop 

Reclassify 

Undelete 

Assign-action 


Model  of  operations 

-  User  gives  User ID  and  is  authenticated  by  the  system 

-  User  invokes  programs  to  perform  the  functions  of  the 

message  system 

-  The  programs  a  user  may  invoke  depend  on  the  user’s  role 

-  A  user  with  the  role  of  System  Security  Officer 

controls  the  clearances  and  roles  assigned  to  User  IDs 

-  Programs  a  user  invokes  may  read,  write,  or  invoke 

objects  or  containers 

-  The  system  enforces  the  security  assertions  listed  below 

(prevents  users  from  performing  operations  that  would 
contradict  then) 


Security  assumptions 

Al.  Security  officer  assigns  clearances  and  roles  properly 
to  users. 

A2.  User  enters  appropriate  classification  when  composing, 
editing,  or  reclassifying  text. 

A3.  User  exercises  proper  control  of  access  control  lists. 


Security  assertions 


Disclosure  of  information 


Dl.  A  user  can  only  view  objects  with  disclosure  level 
less  than  or  equal  to  gib (User  ID, Role,  Output  Device) . 
For  objects  within  containers,  either  the  container’s 
disclosure  level  or  the  object's  disclosure  level 
will  be  checked,  depending  on  the  type  of  the  container 
and  the  mode  of  access  (by  unique  ID  or  pathname) . 


V-5 


Security  assertions  (cont'd) 


Modification  of  information 

Ml.  Users  can  only  modify  objects  with  modification  level 
less  than  or  equal  to  the  gib  of  User,  Role,  and 
Input  Devi.ce  modification  levels. 

M2.  The  disclosure  level  of  any  container  is 
always  at  least  as  great  as  the  maximum  of 
the  disclosure  levels  of  the  objects  and  containers 
within  it. 

M3.  No  classification  marking  can  be  downgraded  except 
by  a  user  with  the  role  of  downgrader. 

M4.  The  clearance  recorded  for  a  UserlD  can  only  be 
set  or  changed  by  a  user  with  the  role  of  system 
security  officer. 

M5.  No  message  can  be  released  except  by  a  user  with 
the  role  of  releaser. 

M6.  No  user  can  invoke  a  program  for  which  his  UserlD 
or  role  is  not  on  the  access  control  list  with  an 
access  mode  of  execute. 


Noteworthy  aspects  of  the  model: 


Multi-level  objects  (containers)  are  defined 

Simple  security  condition  is  reflected  in  Dl. 

*-property  is  not  included,  but  "write-downs"  are  controlled 
via  M2  and  M3 

Integrity  is  included  as  modification  level 

Login  level  is  not  included,  but  I/O  device  abstractions 
can  provide  this  effect 

Programs,  not  processes,  are  included  because  they  are 
more  recognizable  to  users 

Implementation  concepts  (e.g.,  capabilities)  are 
avoided,  but  model  is  designed  to  be  implementable 


Example  regimes  for  accessing  objects  within  containers 


1.  Access  to  object  is  allowed  only  if  the  user  and 
role  clearances  equal  or  exceed  th^  classification  of 
the  container.  If  data  is  copied  from  the  object  to 
another  entity,  that  data  is  treated  as  though  it  had 
the  same  classification  as  the  container. 

[Apply  this  regime  to  aggregation-sensitive  data.] 

2.  Like  (1) ,  but  data  copied  from  the  object  is  treated 

as  though  it  has  the  same  classif icat ion  as  the  object, 
regardless  of  the  container's  classification. 

[Apply  this  regime  to  extraction  of  a  paragraph  of  text  from 
a  message. ] 

3.  Like  (2),  but  only  the  user's  clearance  must  equal  or 
exceed  that  of  the  container. 

[Apply  this  regime  to  viewing  of  messages  within  a  message  file.  1 


Outstanding  issues 

Mathematical  properties  of  the  model 

Possible  abstraction  of  model  for  proofs 

Development  of  design  and  implementation  from  model 

Detailed  design  questions  — 

Determine  whether  each  abstraction  is 
an  object  or  a  container 

Determine  appropriate  regime  for  each 
type  of  container 

Determine  mappings  between  family  members 
that  make  different  container/object 
choices  for  a  given  entity 
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Plans 


Refine/revise  the  security  model 

Integrate  with  MMS  Intermediate  Command  language 
Specification 

Consider  man-machine  interface  questions 

Design  and  develop  prototype  system  based  on 
this  model 
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EUCLID  AND  VERIFICATION 
IAN  GRIGGS 

I.P.  SHARP  &  ASSOCIATES,  LTD. 


THE  (ORIGINAL)  EUCLID  LANGUAGE 

•  MAJOR  APPLICATION: 

PROVABLY  SECURE  SOFTWARE 

•  SYSTEM  IMPLEMENTATION  LANGUAGE 

•  ALLOWS  VERIFIABLE  PROGRAMS 

TO  BE  WRITTEN 


EUCLID  AND  VERIFICATION 

•  THE  EUCLID  LANGUAGE 

•  INTEGRATED  VERIFICATION  SYSTEM 
(EUCLID  +  VERIFICATION  TOOLS) 

•  FUTURE  DIRECTIONS 


HISTORY 

•  DESIGN  COMMISSIONED  BY  DARPA 

•  DESIGNED  BY  EUCLID  COMMITTEE 

•  PASCAL  +  VERIFICATION  FEATURES 

•  PDP-11  COMPILER  FOR  TORONTO  EUCLID 
SUBSET  IMPLEMENTED  BY: 

-  I.P.  SHARP  ASSOCIATES 

-  UNIVERSITY  OF  TORONTO  C.S.R.G. 

•  TORONTO  EUCLID  BOOTSTRAPPED  TO  VAX 


MODULES 

•  RECORDS  WITH  ATTACHED  ROUTINES 

•  INTERFACE  TO  OUTER  PROGRAM 
EXPLICITLY  SPECIFIED 

•  SUPPORT  INFORMATION  HIDING, 
ABSTRACT  DATA  TYPES 

VISIBILITY  AND  ACCESS  CONTROL 

•  MODULES  AND  ROUTINES 
IMPORT  GLOBAL  NAMES 

•  MODULES  EXPORT  INTERFACE  NAMES 

•  READ/ WRITE  OR  READONLY  ACCESS 

ANNOTATIONS 

•  ASSERTIONS 

•  PRE,  POST  FOR  ROUTINES 

•  MODULE  INVARIANT 


RESTRICTIONS  TO  HELP  VERIFIER 

•  NO  ALIASING:  ONE  NAME  FOR 
EACH  DATA  ITEM 

•  NO  OVERLAP 

•  NO  GO  TO  STATEMENT 

•  LEGALITY  ASSERTIONS 

PDP-11  TORONTO  EUCLID  COMPILER 

•  OBJECT  CODE  EFFICIENCY:  VERY  GOOD 

•  COMPILER  SPEED:  SLOW 

-  STRICT  CHECKING  TAKES  TIME 

•  PROGRAMMER  EFFICIENCY:  VERY  GOOD 

-  STRICT  CHECKING  SPEEDS  UP  PROGRAMMING 

•  AVAILABLE:  NOW.  FROM  IPSA 


INTEGRATED  VERIFICATION  SYSTEM 


OBJECTIVES: 

•  EUCLID  AS  IMPLEMENTATION  LANGUAGE 

•  INTEGRATE  EXISTING  VERIFICATION 
TECHNOLOGY 

•  USER-FRIENDLY  CONSISTENT  SYSTEM 

•  RE-USABLE  VERIFIFIED  SOFTWARE  MODULES 

•  MAJOR  APPLICATION: 

PROVABLY  SECURE  SYSTEMS 

STEPS  IN  VERIFICATION  —  SPECIFICATIONS 


REQUIREMENTS 

(INFORMAL) 


SECURITY 

MODEL 


ANALYZE 

SPECS 


MODIFY 

SPECS 


THEORIES 


STEPS  IN  VERIFICATION  -  IMPLEMENTATION 


OTTAWA  EUCLID 


IMPLEMENTATION  EUCLID 


MORE 

EUCLID 

FEATURES 


W-r> 


COMPILATION 


TORONTO  EUCLID 
RESTRICTIONS  REMOVED 


/  i 


•  FUNCTIONS  CAN  RETURN  STRUCTURES 

•  PARAMETERIZED  TYPES 

•  LEGALITY  ASSERTIONS  CHECKED 


ENHANCED  ASSERTION  LANGUAGE 

•  QUANTIFICATION 

•  IF  EXPRESSIONS 

•  SPECIFICATION  FUNCTIONS  AND 
VARIABLES 

•  LEMMAS  AND  AXIOMS 


SEPARATE  VERIFICATION  / 
COMPILATION 

•  STUB  FOR  EXTERNAL  MODULE 
=  SPECIFICATION 

•  LINK-TIME  CHECK  OF 
STUB  VS.  IMPLEMENTATION 


ADVANTAGES 

•  ONE  CONSISTENT  LANGUAGE 

•  TYPE-SAFE  SPECIFICATIONS 
AND  THEORIES 

•  Rt  USE  EXISTING  COMPILER 
SOFTWARE  FOR  TYPE  CHECKING 


FUTURE  DIRECTIONS 

•  LSI  GUARD 

•  CONCURRENCY 

•  OTTAWA  EUCLID  COMPILER 

FIRST  IMPLEMENTATION:  VAX  II 
AVAILABLE  MID  1983 

•  ADAPT  EXISTING  TOOLS  TO 
OTTAWA  EUCLID 


THE  EVALUATION 
OF  THREE 
SPECIFICATION 
and 

VERIFICATION 

METHODOLOGIES 


by 


Richard  A.  Platek 


Digicomp  Research  Corp.  Ithaca,  N.  Y. 


Digicomp  Research  Corp.  is  presently  under  contract 
with  DoD  through  the  Rome  Air  Development  Center  (RADC)  to 
study  and  evaluate  three  spec i f ica t i on  and  verification 
methodologies.  They  are  HDM  (SRI  International) ,  FDM  (or 
Ina  Jo,  SDC )  and  Gypsy  (UTexas)  .  This  thirty  month  effort 
which  began  Sept.  1980  has  three  main  phases: 


a.  Impartial,  critical  analyses  of 
the  methodologies  with  special  attention 
paid  to  their  present  state  of  usability 
by  persons  not  directly  associated  with 
the  developers  and  an  evaluation  of  the 
expertise  required  in  such  a  technology 
transfer . 

b.  Recommendations  for  enhancements 
some  of  which  will  be  subcontracted 
to  the  major  developers  through  Digicomp 
(subject  to  government  approval)  while 
others  will  be  used  to  drive  further 
funding  through  other  agencies. 

c.  The  design,  implementation  and 
verification  of  a  secure  data  base 
management  system  using  each  of  the 
methodologies.  The  mathematical  model  of 
such  a  secure  DBMS  is  based  on  previous 
work  by  I.  P.  Sharp. 

The  first  and  most  of  the  second  of  these  phases  have 
been  completed  while  the  third  is  underway.  In  this  talk  I 
would  like  to  describe  some  of  our  findings  so  far.  The 
work  has  been  performed  by  Tanya  Korelsky,  Len  Silver  and 
myself.  As  an  indication  of  our  backgrounds  I  should  state 
that  all  three  of  us  have  Ph.D.s  in  Mathematics  but  no  prior 
experience  in  verification. 


Like  many  developing  software  systems  the^e 
methodologies'  documentation  sometimes  contain  features 
which  have  not  yet _been  implemented.  Considering  the  fact 
that  these  implementations  are  ongoing  our  remarks  could 
best  be  treated  as  time-stamped  snapshots  of  evolving 
systems.  Furthermore,  since  these  tools  have  not  been 
subjected  to  extensive  use  outside  of  their  places  of  origin 
it  is  important  to  obtain  independent  evaluations  based  on 
sustained  hands-on  experience.  The  comparative  method  that 
has  been  chosen  seems  to  us  and  our  sponsors  to  be  the  best 
technique  for  revealing  the  strengths  and  weaknesses  of  the 
existing  methodologies  and  for  making  recommendations  that 
could  be  incorporated  in  future  specification  and 
verification  work. 

Although  we  will  briefly  review  the  paradigms  which 
underlie  each  of  the  methodologies  our  time  constraint 
forces  us  to  assume  that  the  hearer  has  been  exposed  to  more 
detailed  descriptions  of  the  methodologies  as  they  have  been 
described  by  their  developers  at  these  and  similar  meetings. 

I .  HDM 

The  present  situation  with  HDM  is  quite  complicated 
due,  in  our  opinion,  to  the  large  turnover  in  extremely 
talented  personnel  at  SRI  who  have  been  involved  over  the 
years  with  the  HDM  project  and  the  absence  of  a  central 
authority  who  would  have  had  the  power  to  curtail  creativity 
in  the  interests  of  consistency.  While  such  a  production 


system  orientation  is  inconsistent  with  research  no.il  :  and 
verification  as  a  whole  has  benefited  from  SRI's  experiments 
it  is  a  fact  that  HDM  presently  consists  of  several  well 
thought  out  and  engineered  components  that  lack  integration. 
Although  SRI  is  aware  of  this  problem  and  it  is  currently 
being  addressed  by  ongoing  work  in  is  fair  to  say  t  ha'-  at 
present  an  outs  der  can  not  use  HDM  to  design,  implement  and 
verity  a  program  from  beginning  to  end.  Although  .  ■ur  etuiy 
was  completed  last  ►'larch  and  reflects  the  system  as  it  was 
then  we've  kept  abreast  of  the  more  recent  changes. 

HDM  specifications  are  written  in  SPECIAL  a 
non-procedural  strongly  typed  assertional  language  based  on 
first-order  logic.  The  unit  of  spec i f i ca t i on  is  the  module 
which  is  an  encapsulated  abstract  data  type.  Following 
Parnas  modules  are  described  as  abstract  automata  defined  in 
terms  of  states  and  state  transforms.  (We  prefer  the  terms 
"state"  and  "transform”  to  the  awkward  "V  Function"  ani  "O 
Function"  terminology;  unfortunately  SPECIAL  maintains  the 
original  Parnas  nomenclature  which  is  confusing  to  now 
users.  Ina  Jo  uses  the  terms  "variable"  and  "transform", 
the  state  being  the  values  of  all  the  variables  at  any  given 
moment.)  These  modules  are  grouped  together  to  form  virtual 
machines  which  in  turn  are  levels  in  a  hierarchy.  The  top 
level  of  this  hierarchy  is  the  user  interface  while  the 
bottom  is  the  "machine"  on  which  the  system  is  to  run;  the 
latter  is  not  necessarily  a  physical  machine  but  can  be  a 
combination  of  hardware  and  software,  for  example  a  PASCAL 
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or  ADA  machine.  Adjacent  levels  are  related  by  mappi n  js 
which  are  of  two  kinds.  The  state  or  data  mappings  provi  ;<• 
an  image,  Image(S),  on  the  upper  level  for  each  lowvr  le.-el 
state  S.  These  are  described  using  SPECIAL  expressions. 
The  transform  or  procedure  mappings  express  each  higher 
level  state  transform  T  as  a  program  P(T)  which  "runs"  on 
the  lower  level  machine  and  calls  lower  level  state 
transforms.  P(T)  is  correct  if  whenever  it  drives  the  lower 
state  SI  to  the  lower  state  S2  then  Tf Image (Pin  is 
T  (Image (S2) )  .  Said  simnly  this  means  that  the  program  P(T) 
simulates  T  on  the  lower  machine.  The  program  p  is  written 
in  the  target  HOL.  In  the  original  HDM  conception  a  new 
programming  language,  ILPL,  was  designed  for  this  purpose 
but  this  approach  has  been  abandoned.  When  all  the  P(T1 
have  been  verified  to  he  correct  the  transform  mappings  cat 
be  composed  to  yield  a  complete  verified  implementation  of 
the  top  level  virtual  machine  on  the  bottom.  The 
composition  of  transform  mappings  is  reflected  in  the 
resulting  program  by  procedural  call  nesting;  the  depth  of 
this  nesting  being  essentially  the  length  of  the  hierarchy. 

Unfortunately  the  specification  language  SPECIAL  comes 
in  several  variants.  First  there  is  the  original  version  of 
SPECIAL  which  we  will  call  Handbook  SPECIAL.  The  publicly 
available  HDM  automated  tools  which  check  for  syntax 
correctness,  hierarchical  consistency  and  certain  forms  of 
completeness  are  written  to  this  SPECIAL.  These  tools 


contain  bugs  which  were  discovered  in  the  course  of 
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testinq.  These  bugs  have  not  been  corrected  for  reasons 
outlined  below. 

Handbook  SPECIAL  contains  many  features  which  its 
designers  thought  would  be  useful  in  specifying  complex 
systems.  This  compounding  of  features  led  to  a  language 
without  a  clear  semantics  (or  perhaps  a  better  way  to  say  it 
would  be  a  languaqe  susceptible  to  several  overlapping 
semantics) .  For  example,  a.  First  order  xogic  is  used  to 
express  system  states  before  and  after  transforms  are 
called,  b.  A  New  operator  creates  new  objects  of  a  certain 
kind  of  type  when  called,  c.  Exception  conditions  for 
transforms  must  be  evaluated  in  a  certain  order,  d.  There 
are  unusual  constructs  like  "Delay  Until".  Because  of  the 
incompatibility  of  the  various  semantics  of  these  languages 
it  was  found  to  be  necessary  to  subset  SPECIAL  whenever  any 
design  or  code  verification  issues  arose.  For  example,  SRI 
produced  a  multilevel  security  information  flow  analysis 
tool.  This  works  on  the  top  level  SPECIAL  spec  and  uncovers 
information  flow.  The  tool  is  very  conservative  and 
considers  an  information  flow  to  occur  between  variables 
whenever  the  former  is  referenced  in  any  way  by  the  latter 
(e.g.,  in  the  assignment  statement  vl  :=  0*v2  information  is 
assumed  to  have  flown  from  v2  to  vl).  In  order  to  make  this 
analysis  it  was  found  necessary  to  restrict  the  kind  of 
expressions  that  occur  in  specs.  This  gives  rise  to  MLS 
SPECIAL.  Every  variable  at  the  top  level  is  assigned  a 
security  level  and  the  MLS  tool  checks  that  information  only 


flows  upward  in  level.  To  do  this  it  produces  formulas 
which  are  handed  over  to  the  Boyer-Moore  theorem  prover. 
The  latter  has  its  own  language  designed  according  to  very 
different  principles  than  those  that  govern  SPECIAL. 

HDM's  original  attempt  at  code  verification  involved 
the  use  of  a  pseudo-assembly  language  CIF  (Common  Internal 
Form)  set  up  within  Boyer-Moore  theory.  A  MODULA  translator 
translated  MODULA  code  into  CIF  and  the  latter  was  proved 
correct  within  Boyer-Moore  theory.  In  order  to  do  this  the 
SPECIAL  specs  had  to  also  be  translated  into  Boyer-Moore.  A 
very  impoverished  subset  of  SPECIAL  was  developed  called 
VSSL.  No  automated  tools  were  provided,  the  program  had  to 
be  respecified  in  VSSL.  There  are  many  d i screpanc ies 
between  SPECIAL  and  VSSL.  VSSL  and  CIF  for  example 
understand  integer  to  be  non-negative  while  SPECIAL  and 
MODULA  understand  integer  to  be  positive  or  negative.  VSSL 
does  not  allow  any  existential  quantifiers  in  the  effects 
section  of  a  transforms  spec.  Furthermore  all  the  code 
verification  required  large  amounts  of  manual  intervention 
to  add  statements  necessary  to  achieve  a  proof.  The 
smallest  programs  took  an  enormous  amount  of  time  to  verify 
and  when  done  it  was  not  clear  what  had  been  verified  since 
VSSL  was  not  SPECIAL  and  CIF  was  not  MODULA. 

As  part  of  the  SIFT  project  SRI  is  developing  a  PASCAL 
verification  system  for  HDM .  This  has  involved  a  new 
version  of  SPECIAL,  Pascal  SPECIAL,  and  tools  to  check  it* 
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tile  ab-  ve  went  i  oned  buqs  in  tin’  exist. in:  ;  v  •  ..  a 

no  t  boen  fixed.  The  concept  <>t  f'  1  h  hi  !■•■ 

Instead  .t  Meta-Vcg  his  been  built  wh  i  .Mi  i  ’  .  •: .  • 

definition  of  a  programming  language,  cede  in  t :  i .  >  *  i  o.i  . ,  n- 
and  specs  and  then  generates  VCs  directly.  >r  i  tin  i  i  i  y  t  »••• 
VCs  were  in  Boyer-Moore  theca  y.  Boyer  and  Mr  ••..•re  nav’  '  t  h 

recently  Left  SRI  to  join  the  University  of  Texas.  As  a 

result.  SRI  has  begun  adapt  i  ng  II  DM  to  run  with  the  Shostak 
theorem  prover .  The  Meta-Vcg  for  example  will  output  Vcs  in 
either  Rover-Moore  or  Shostak  theory.  We  have  not  had  any 
experience  with  the  latter  .  Unfortunately  Pascal  SPMOIAL 
does  not  contain  MLS  SPifCIAI.  as  a  subset  s-  •  that  the  Pascal 
system  as  it  now  stands  can  not  be  used  fd.r  security  proofs. 


As  a  result  of  these  nicer t  aiut i os  niqicomp 
subcontracted  with  Sytek  to  do  a  stub  of  t.ho  SPKdlAL 
dialects  and  make  recommend  at  ion:;  for  st  an  i  ard  i /at  i  on.  Th  s 
study  is  being  directed  by  Rich  Peiertaq  a  farmer  SRI  member 
and  pt  incipal  dosi  (net  of  the  MLS  tool  .  It  will  be 
completed  in  Sect.  We  hope  someone  will  be  in  a  position  to 
act  on  the  recommendations  in  the  report  which  from  what 
we've  seen  is  very  thouqhtful. 


At  SRI  work  is  proceedinq  in  matching  the  RDM  tools 
more  closely  with  the  Shostak  theorem  prover,  in  developing 
proof  rules  to  deal  with  full  concurrency,  and  with 
developinq  a  new  spec i f i ca t i on  language  called  ORDINARY. 
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incomplete  abstract  description  of  the  find  -vs  tom  w; 
omits  certain  design  decisions  and  contains  the;  .  .r, 

mathematically,  the  top  level  is  a  speci  f  icat  ion  .f  i  : 
of  systems  one  of  which  is  the  intended  fiml  system, 
subsequent  level  also  defines  a  family  of  system-.  As 
HDM  t'ne  mappings  between  levels  relate  t  iso  s*  at  os  ■  ‘ 
lower  to  the  states  of  the  higher  and  the  transforms  .f 
higher  to  the  transforms  of  the  lower.  They  are  sai  1  t 
correct  for  each  adiacont  pair  if  the  family  of  sys 
specified  by  the  lower  is  a  subset  of  the  family  of  cyst 
specif  it'd  by  the  upper  relative  to  the  mappinas  whi 
like  a  dictionary  enabling  one  to  translate  hiiher  1 
expressions  into  lower.  Thus  each  level  can  be  thou  pit 
as  a  refinement  of  its  predecessor.  This  t<»  fine- 

proceeds  by  adding  further  detail  and  concretion. 

Levels  are  described  using  Ina  Jo,  a  specif icat 
language  similar  to  SPECIAL  but  cleaner  in  syntax 
semantics.  Untike  SPECIAL  only  one  kind  of  semantics, 
involved,  namely  first  order  logic.  This  leads 
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simplicity  in  expression  and  ease  of  provability.  The  cost 
is  lack  of  expressiveness  but  Ina  Jo  is  presently  beinq 
upgraded  to  include  more  extended  expressiveness. 

Ina  Jo  provides  a  means  for  proving  that  the  top  level 
spec  satisfies  user  supplied  design  criteria.  These  are 
written  in  Ina  Jo  and  are  syntactically  part  of  the  top 
level  spec.  Only  experience  will  show  whether  this  approach 
is  adequate  f<  r  the  expressing  of  interesting  security 
properties.  In  order  to  prove  these  design  criteria  for  the 
top  level  one  submits  ‘he  spec  to  the  language  processor 
which  produces  candidate  theorems  the  truth  of  which  imply 
that  the  criteria  holds  of  all  systems  that  satisfy  the  top 
level  spec.  These  theorems  are  proved  using  the  associated 
ITP  (Interactive  Theorem  Prover)  .  The  latter  is  simple  to 
use  and  well  integrated  into  the  system.  It  is  not  very 
powerful  but  is  continually  being  upgraded.  It  contains, 
for  example,  very  little  arithmetic  since  there  has  been 
very  little  need  for  it  in  the  projects  SDC  has  used  Ina  Jo 
on . 


State  mapping  between  adjacent  levels  are  essentially 
the  same  as  HDM  but  the  transform  mappings  are  logical 
rather  than  procedural.  It  T  is  an  upper  level  transform 
then  the  mapping  of  T,  M(T),  is  essentially 

IF  CONDI  THEN  D1  ELSE 
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IF  C0ND2  THEN  D2  ELSE 


IF  C0ND3  THEN  D3  _  where  the  COND's  are  Ina  Jo 

Boolean  expressions  describing  subsets  of  the  lower  level 
state  space  and  the  D's  are  lower  level  transforms.  With 
respect  to  these  mappings  one  proves  that  each  subsequent 
level  is  a  refinement  of  its  predecessor.  As  in  the  case  of 
the  proof  of  the  top  level  design  criteria  candidate 
theorems  are  produced  by  the  language  processor  from  each 
pair  of  adjacent  levels  and  these  are  proved  using  the  ITP. 

All  that  we  have  described  so  far  is  implemented  but  we 
should  remark  that  when  all  this  proving  is  completed  one 
still  has  not  verified  any  HOL  code  let  alone  written  it. 
This  is  not  meant  to  imply  that  describing,  refining,  and 
proving  the  specifications  in  this  way  is  without  value.  We 
did  not  encounter  serious  difficulty  in  using  the  system. 
Since  the  ITP  is  weak  many  "self-evident"  axioms  had  to  be 
manually  added  to  finish  proofs.  This  is  obviously  a 
dangerous  procedure  in  verification  since  "self-evident" 
sometimes  turns  out  to  be  false.  We  have  made  SDC  aware  of 
all  bugs  and  unimplemented  details  we  have  come  across  and 
they  intend  to  act  on  them.  FDM  was  produced  primarily  with 
internal  SDC  funds  and  is  a  proprietary  product.  Since  it 
is  fashionable  in  Washington  nowadays  to  extol  the  spiritual 
values  of  capitalism  one  should  remark  here  that  private 
property  tends  to  be  kept  up  by  its  owners. 
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We  now  describe  SDC's  intentions  with  resaect  to  cole 
verification.  In  FDM  all  code  verification  will  be  done 
after  all  levels  have  been  designed  and  proved.  Beneath  the 
bottom  level  Ina  Jo  spec  there  will  be  an  implementation 
level  which  relates  the  bottom  level  Ina  Jo  variables  and 
transforms  to  the  names  of  HOL  variables  and  transforms.  An 
extension  of  the  language  processor  not  yet  implemented  will 
take  this  level  and  generate  entry  and  exit  conditions  for 
the  HOL  procedures.  These  together  with  HOL  code  will  yield 
VCs  when  passed  through  a  VCG  (a  MOD'JLA  VCG  for  Ina  Jo  entry 
and  exit  conditions  is  near  completion).  In  addition  in 
order  to  show  that  the  resulting  program  is  an  instance  of 
the  family  of  systems  specified  by  the  Ina  Jo  s>  ■  ■  i'  will 
be  necessary  to  check  that  in  the  resulting  m.im  er  pr^ir.im 
the  entry  conditions  for  each  HOL  proce  .ure  hold  whenever  it. 
is  called.  The  reason  the  mappings  of  transforms  between 
levels  are  restricted  to  the  form  we  .escribed  is  to  make  it 
possible  to  assemble  mechanically  the  entry  conditions  for 
each  HOL  procedure.  This  is  a  subtle  point  not  mentioned  in 
SDC  documentation  and  was  the  cause  of  some  misunderstanding 
among  outside  students  of  Ina  Jo. 

Much  work  remains,  to  be  done  to  complete  the  code 
verification  aspects  of  Ina  Jo  and  Digicomp  expects  to  fund 
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modularity  the  amount  of  work  to  be  done  at  node 
verification  time  may  be  inordinately  large  and  various 
means  to  structure  it  may  have  to  be  devised.  The  theorem 
prover  will  need  to  be  upgraded  to  handle  the  full  spectrum 
of  mathematics  that  occurs  in  program  verification. 

III.  GYPSY 

Unlike  HDM  and  FD*'!  Gypsy  is  both  a  programming  and 
specification  language.  Gypsy  text  appears  like  a  Pascal 
program  in  which  spec i f i cat i ons  are  interspersed  at  key 
points.  For  example,  every  procedure  and  function  has  entry 
and  exit  assertions  and  every  loop  is  broken  by  at  least  one 
assertion.  Verification  conditions  are  generated  from  these 
specifications  and  code,  and  these  VCs  are  submitted  to  an 
integrated  theorem  prover.  This  is  the  central  loop  of  the 
Gypsy  Verification  Environment  (GVE) .  This  environment  is 
quite  congenial.  It  contains  a  library  manager  which  keeps 
track  of  the  various  parts  of  the  verification  process  and 
their  status,  an  internal  structured  editor  and  links  to 
external  editors  like  emacs,  facilities  to  incrementally 
write  and  prove  code,  etc. 

As  a  result  of  the  integrated  language  there  is  no 
strict  separation  of  design  and  implementation  in  Gypsy. 
The  user  can  shade  a  Gypsy  source  text  heavily  towards  the 
one  or  the  other.  It  could  be  pure  specification  with  ik. 
code  or  pure  code  with  no  specification.  The  latter  is 
compilable  with  PDP-11  object  code. 


As  mentioned  above  the  Gypsy  environment  lends  itself 
to  incremental  usage.  Pieces  of  program  are  written  and 
verified.  Some  of  these  pieces  are  high-level  routines  and 
some  low-level.  The  bodies  of  the  latter  may  be  left 
pending  while  their  entry  and  exit  assertions  are  used  to 
prove  the  correctness  of  the  high  level  routines.  The 
system  could  be  used  as  a  vehicle  for  many  design  strategies 
such  as  "stepwise  refinement",  top-down",  etc. 

Gypsy  also  provides  a  limited  form  of  concurrency 
through  the  use  of  buffers  that  simultaneous  running 
processes  can  send  to  or  get  from.  Proof  techniques  have 
been  developed  to  handle  the  logic  of  this  kind  of 
concur  rency . 

Gypsy's  claim  to  fame  is  that  one  can  actually  produce 
verified  code.  The  main  caveat  seems  to  be  that  since  the 
specification  is  so  close  to  the  implementation  level  it  is 
not  simple  and  abstract  enough  to  get  a  firm  grasp  on  what 
has  been  proved  about  a  large  system.  It  lacks  for  example 
Ina  Jo's  facility  of  expressing  a  design  criteria  at  a  high 
level  and  then  using  mappings  as  a  dictionary  to 
unabbreviate  it  down  to  a  condition  on  actual  program 
variables.  Gypsy  does  recognizes  the  need  to  provide 
mechanisms  of  abstraction  so  that  the  intent  of  the  code 
becomes  more  transparent.  But  it  seems  that  this  goal  was 
given  a  lower  priority  than  the  the  admirable  one  of 
producing  a  system  in  which  one  can  develop  verifiable  and 
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compilable  code.  One  such  abstraction  mechanism  is  a  form 
of  abstract  data  types  using  access  lists.  It  is  described 
in  the  Gypsy  language  manual  but  hitherto  not  implemented. 
This  is  one  of  the  enhancements  currently  being  funded  by 
Dig icomp. 

Although  Don  Good  and  his  senior  assistant  Rich  Cohen 
have  been  with  the  system  since  its  inception  many  people 
have  worked  on  Gypsy  as  graduate  students  at  UTexas.  This 
is  reflected  in  a  certain  uneveness  in  the  components.  An 
embarrassing  example  is  that  although  unproved  lemmas 
sometimes  have  to  be  added  to  the  knowledge  base  in  order  to 
complete  proofs  their  status  as  unproved  can  be  forgotten  by 
the  system.  Digicomp  is  funding  a  top  level 
reimplementation  which  will  address  some  of  these  issues. 
This  will  be  done  in  a  yet  to  be  finalized  dialect  of  LISP 
with  portability  a  major  concern  in  the  choice.  The  present 
version  is  written  in  UCI  LISP  running  under  Tops-20  and 
runs  into  space  problems  when  verifying  medium  size 
prog  rams . 

From  a  logician's  point  of  view  the  major  criticism  of 
the  system  is  that  it  deals  only  with  partial  rather  than 
total  correctness  as  these  terms  are  used  in  the  field  of 
program  verification.  This  means  that  is  no  mechanism  is 
provided  to  prove  termination  of  subroutines.  All  functions 
are  dealt  with  by  the  theorem  prover  as  if  they  were  total 
and  in  this  way  an  unsoundness  could  be  introduced.  The 
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MODULA-CIF  version  of  HDM  attempted  to  deal  with  this 
problem  through  the  use  of  a  user  supplied  clock  function. 
Ina  Jo  has  not  faced  this  issue  yet. 

1  would  now  like  to  mention  some  areas  for  possible 
research. 

L.  There  is  a  need  for  an  understandable,  intelligible 
specification  language.  The  present  specification  languages 
are  like  the  "machine  language"  of  specification  languages. 
They  are  difficult  to  read,  too  homogeneous.  It  seems  the 
proper  constructs  peculiar  to  specification  remain  to  be 
d i scove  r ed  . 

2.  Theorem  proving  is  the  big  bottleneck  in  code 
verification.  Proof  checkers  are  too  pedestrian  and  the 
automatic  ones  run  away.  The  ideal  would  be  a  system  which 
could  take  a  sketch  of  a  proof  and  expand  it  into  a  real 
proof.  1  don't  believe  this  is  an  impossible  goal,  I  do 
believe  it  is  a  necessity  if  large  scale  code  verification 
is  to  become  a  reality  but  I  also  feel  it  requires  a 
significant  breakthrough  in  the  field  of  automatic  theorem 
proving.  The  latter  is  a  pure  research  area  involving 
mathematics,  logic,  und  artificial  intelligence. 

3.  Integration  seems  to  be  the  key  to  success  in  this 
area.  Ina  Jo  is  weaker  piece  by  piece  than  HDM  but  the 
integration  the  system  has  compensates.  Gypsy  is  the  most 
satisfying  to  work  with  because  of  its  integration. 
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•1.  Finally  I  would  like  to  mention  the  pout;  i  b  i  1  i  t 
using  approaches  to  code  verification  other  tha 
generation.  There  are  several  such  methods  available 
alio'  one  to  use  the  urogram  text  itself  in  prods  r 
than  translations  of  it  info  another  lanpiair. 
advantages  of  the  vcg  approach  is  'hat  tie  -an  use  :<• 
purpose  theorem  pr  overs  since  the  VC. a  are  n  *  a  t  ‘ 

ordinary  mathem.at  .cal  language.  The  advantage  tii 
VCG  approach  is  further  inteqrat i  n  an i  unity.  Th* 
translation  from  one  language  t.;  an-  -t  her  the  treat -.'i 
for  success. 
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COMPUTER  SECURITY  RELATED  PUBLICATIONS 


Listed  below  are  titles  and  accession  numbers  of  some  computer  security 
related  publications  which  are  now  available  from  the  Defense  Technical 
Information  Center  (DTIC),  Defense  Logistics  Agency,  Building  5,  Cameron 
Station,  Alexandria,  Virginia  2231^  (Phone  202-274-7633,  AUTOVON  284-7633). 

Firms  or  individuals  registered  with  the  DTIC  may  obtain  copies  for  a  flat  fee 
per  document.  Those  who  are  not  registered  with  the  DTIC  may  obtain  copies 
from  the  National  Technical  Information  Service,  5285  Port  Royal  Road, 
Springfield,  Virginia  22161  Orders  may  be  placed  or  price  quotations  may  be 
obtained  for  each  document  by  calling  703-487-4650. 

AD  A101  996  Proceedings  of  the  Third  Seminar  on  the  DoD  Computer  Security 

Initiative 

AD  A101  997  Proceedings  of  the  Second  Seminar  on  the  DoD  Computer 

Security  Initiative 

AD  A101  998  Proceedings  of  the  Seminar  on  the  DoD  Computer  Security 

Initiative  -  (First  Seminar) 

AD  076  617  Security  Controls  for  Computer  Systems  Report  of  DSB  Task 

Force  on  Computer  Security  (Rand  Ware  Report,  October  1979) 

AD  A103  399  TRUSTED  COMPUTER  SYSTEMS  -  Needs  and  Incentives  for  Use  in 

Government  and  the  Private  Sector  (Rand  Turn  Report,  June 
1981) 

AD  A095  409  Modernization  of  the  WWMCCS  Information  System  (WIS)  (DCA) 

January  1981 

AD  A108  829  Trusted  Computer  Systems-Glossary  (Huff,  MITRE),  March  1981 

AD  A108  827  Computer  Security  Bibliography  (Discepolo,  MITRE)  November 

1980 

AD  A108  828  Industry  Trusted  Computer  System  Evaluation  Process  (Trotter 

and  Tasker,  MITRE)  May  1980 

AD  A108  830  History  of  Protection  in  Computer  Systems  (Tangney,  MITRE), 

July  1980 

AD  A108  831  Specification  of  a  Trusted  Computing  Base  (TCB)  (Nibaldi, 

MITRE)  November  1979 
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Proposed  Technical  Evaluation  Criteria  for  Trusted  Comput 
Systems  (Nibaldi,  MITRE)  October  1979 

Formal  Specifications  of  KVM/370  Kernel  and  Trusted 
Processes  (Gold  and  Thompson,  SDC)  May  197# 

Final  Report  VM/370  Security  Retrofit  Program-Detailed 
Design  and  Implementation  Phase  (Gold  and  others,  SDC) 

May  1978) 

Semi-Formal  Description  of  KVM/370  Trusted  Processes 
(Thompson,  SDC)  December  1977 


